Unununium Operating Engine

A quick search on CiteSeer revealed a paper entitled “SL Synchronous Language”, written by Frederic Boussinot and Robert de Simone.

The language is a subset of Esterel which attempts to solve the presence and absence hypothesis related to the detection of absent signals.  In general, it can be seen as a reactive model allowing the modelisation of signal propagation to carry a program from state A in instant t1, to state A’ in instant t2. As with many synchronous languages, it implements some form of petrinet; it allows to model parallel behaviour while maintaining some sanity. 

Reading on Esterel, SL, Axum and many other languages, I believe it may be important to support parallel execution and the model I feel the most comfortable with at the moment is one allowing execution of time-limited instants, with transitions from instants to instants in a controlled and time bounded environment, while also allowing in parallel unbounded and asynchronous program execution.

There should be a possibility to create simultaneous timed-environment operating at differing intervals; the shortest interval should get executed first.  There should also be a possibility to group together multiple transitions and allow this group to either succeed or fallback to a previous state.

This same ‘group’ model could probably have a defined set of conditions that must be met; which would reside outside of any transition and be checked automatically at the completion of all the transitions.  If the conditions fail, it could automatically revert back to a given state, the previous state, temporarily/permanently disable this group of transitions or set some places to fire “corrective” transitions.

The untimed transitions would simply be allowed to fire at will, although some controls may need to be introduced on token consumptions when a place is shared between timed and untimed transitions to prevent the untimed transition to starve the timed transition. 

Places should be bounded to limit memory consumption.  Transitions should be boundable to limit the number of parallel fireable transitions.  By limiting a transition to a single instance and placing the requests in an inbound place, it would allow a guaranteed unique execution of that piece of code without a requirement for a mutex.

Obviously a lot more would need to be precised, defined and documented.  But I believe things may be taking shape… finally!