17/10/2006
--------------------------------------------------------------------------------
SugarCubes v4.0a5
--------------------------------------------------------------------------------
Warning: this release is still in alpha stage. APIs are not stabilized and can
evolve until the beta stage is reached. Many mechanisms are still not fully
implemented or even are not implemented at all. And of course, a lot of bugs may
be still hide around. Until the beta stage, new features can be added and also
can be dropped. This release is intended for evaluation purpose only.
--------------------------------------------------------------------------------
This new release provides many improvements over the SugarCubes v3.x:
* On the user API side:
- Methods of InternalIdentifiers interface of the user API has changed their
names:
* identifierFromString becomes getIdentifierFromString
* cubeDestructionIdentifier becomes getCubeDestructionIdentifier
- The following methods are dropped:
* threadStepIdentifier which was renamed as getThreadStepIdentifier
* threadFinishIdentifier which was renamed as getThreadFinishIdentifier
- added the notion of event environment in the user interface. Now
the InternalIdentifiers interface has four new methods (lookup, bind, cleanup
and makeNewEnvironment) allowing the user to implement its own binding
mechanism between events and their identifiers. This mechanism is used
internally by the execution machine. This allows one to implement efficient
lookup mechanism well adapted to a particular application. For example one
can use spacial coordinate based identifiers to retrieve events on a geometric
scope.
As an example a new class InternalGridIdentifiers is provided to show how to
deal with event stored on arrays and accessible by an index number as
identifiers.
- added a new method to export reactive program as an XML document. Very early
stage, this still needs a general format for the XML document. At that time it
is not fully implemented, making it useless. The goal is to achieve an XML
representation of the program usable as an alternative to the serialization
mechanism which is not present on embedded version of Java (J2ME). It can be
also interesting to explore XSLT transformations on the code tree.
- added an experimental way to define private identifier of events. This allows
one to declare statically events identifiers. It can be used to ensure that
programs communicate using the same event, thanks to the Java compiler which
can check that identifier has been declared first. This mechanism can also
facilitate garbage collection of events no more used (using Weak References
to store events in the environment which is not the case at this time for
compatibility reasons with version 1.1 of Java and J2ME). Issues using this
mechanism and code migration or using the same internal event identifiers in
different reactive machines are still not fully be addressed. So this mechanism
will evolve until the beta stage.
- added exec instructions which is similar to the run instruction, it allows
one to instanciate dynamically a piece of code to be executed at runtime.
- added flipflop instruction allowing to suspend and resume execution of a
program with a single event. The same event is used to suspend a running
program or to resume the suspended program.
- modified semantics of the shell instructions which are now extensible only by
instructions in their own body. shells can also listen to an event to look for
programms to add at the next activation.
- modified semantics of freezable instructions which no more une a name, but
await for an events. But semantics is still close to the old one in comparaison
to what is done in Junior.
- reactive machines are split in two distinct objects : Machine and Clock. The
main consequence of that change is reactive machines (interface Machine) are no
more considered as Instructions but one introduces the Clock instruction which
more or less play the same role as the old reactive machine instruction do.
So now clocks are Cubes which define their own sequence of instants and their
own event environment. On the other side machines are responsible of handling
the processor (the execution thread) to compute instants. Machine can no more
be migrated from reactive sites to reactive sites as in previous versions of
SugarCubes but clocks can.
- the ability to access the values associated to an event during the previous
instant is no more supported. The method still exist in the environment for
compatibility with the Junior kernel. But this will be probably dropped when
SugarCubes come to the beta stage.
- Clocks which are activated within a reactive machine are also designated by a
ClockIdentifier and register themselves in a global registry.
- One allows (asynchronous) generation of events into a specific clock which is
designated by the ClockIdentifier of the clock. Specific methods have been
added in the SC class : generateEventInClock and generatePureEventInClock.
- added an addInputs method to add an array of new Events for the next
reaction.
- added a new instruction Emit which allows a new model of communication and
partial synchronization between two clocks. Events are bound to a specific
clock. When a clock c1 (has a program which) emits an event e in clock c2 the
emitter stops its execution (the emit returns WAIT) until the receiver has
taken into account the new event (the emitter terminates the emit instruction
when it is sure that the emitted event has been received by the target clock).
This allows a weak synchronization between a sequence of a program in the
emitter clock and the target clock.
Moreover, when two events are emitted at the very same instant in the same
clock (ie emit A and emit B are simultaneously activated) targeting the same
receiving clock, then the emitter is guaranteed that the two emitted events are
perceived simultaneously in the target clock. In the same way, if an event A is
emitted and then in an instant later an event B is emitted from the same clock
c1 targeting altogether the same clock c2, the emitter is guaranteed that event
A will be present one (or more) instant before B in the targeted clock c2.
These properties are important guaranties since emission are processed
asynchronously between the two clocks.
The main issue not fully addressed here is how to ensure that the
size of queues handling asynchronous emissions will be finite. So this
mechanism should evolve by the end of the alpha stage.
- Added specific Input, Output and Error streams which are redirected to
standard java streams by default, but can be bound to any other streams.
- A reactive machine is now an extension of the Runnable interface allowing one
to use Reactive Machine with a Java Thread. the run method will cyclically
make the machine react until its completion. One can still parameter execution
of that Machine by setting the inter-instant time interval. One can also
activate or deactivate the prompt on the standard output.
- modification of loop instructions. for example adding a break instruction
to finite loops with body instantaneously terminating, which so can not be
preempted using classic preemption instruction. The break will preempt the
execution of the loop at the end of the current iteration. Cyclic instructions
can also allow a max number of instantaneous iterations to give more
flexibility.
- adding an exception mechanism which allows to handle problems that can occurs
during execution of an atomic action or during asynchronous emissions.
- adding a Try instructions to handle exception
- adding refresh events channel for clock to clock communication channel. This
allow a clock to send an event at one instant to discard previous emissions.
- adding a customized way to handle outpout streams (i/o).
TODO:
- complete the implementation of the XML representation of a reactive program.
- complete the implementation of the emit instruction and machine and clock
registration mechanism.
- adding a the ability to bind a program to an external clock allowing to await
and synchronize instants with another program on a shared (and possibly
distributed) clock. In this model atomicity of external operations (java
actions or java expressions) are preserved according to local original clock.
While semantic of reactive instructions is defined by reference to the notion of
instant provided by the shared clock.
- campact code of the merge operator
- cleanup code.
- more and more tests and debug.
* On the implementation side:
- The reset mechanism has been replaced by a new execution mechanism, avoiding
the need to reset an instruction even in a loop. As reactive systems are often
cyclic systems this should be a better way to handle large systems.
- The new execution mechanism distinguishes activation at the end of instant
and other activations during the instant within a specific method
activateAtEOI. This simplify activate method and can result in some cases to
little speed up.
- Early implementation of the ThunderBolt algorithm, mainly based on Storm.
This algorithm keeps memory of the reactive programs blocked on event
configurations between consecutive instants the same way the Simple algorithm
does in Junior. The main difference here is that the semantics of the Merge
instruction is preserved and so semantics doesn't rely at all on event queues
policies.
- Re-implementation of instructions with static identifiers and data in order
to get better performances, and ability to optimize code when added to the
reactive machine. This allows cyclic programs using static identifiers to refer
to events without having to lookup uselessly events in the environment at each
iteration.
Have fun!
Jean-Ferdy