Re: Definition of ``codel'' + ``execution engine'' ...

Herman Bruyninckx wrote :
| Codel: any part of a component that must be executed atomically,
| within the context of this component. In this sense, it is the basic
| building block of an Execution engine.
| It is important to stress that the atomicity must hold only within the
| component only; the operating system can preempt the codel by
| scheduling of other components. (Unless the codel takes explicit
| actions to make pre-emption impossible.)

Cezary Zielinski wrote :
| CODEL - is a piece of code and variables local to it, that is
| designated for execution by the execution engine. Codel's execution
| should never be interrupted by the execution engine.  The return code
| (state) of the codel enables the execution engine to make decisions as
| to the designation of the next codel (perhaps more than one if parallel
| execution is possible) for execution.

I basically agree with the two definitions (which are actually very close
to eachother).
[Herman] Just one remark: codels should never make explicit actions to
make preemption impossible!
[Cezary] We never considered parallelizing codels within *one* service. I
think this would be possible, but this would also raise new, non-trivial,
implementation problems (e.g. joining parallelized codels?) and this
would break the property that one single service executes within one
single thread. Of course it is still possible to run several services in
parallel.
Unless someone sees a real need, I propose to limit (at least for 1.0
design :) to one single state (codel) at a time.

Sara came up with a combination of the two definitions (that I append a
bit with the 'atomicity' property, ok Sara ?):

CODEL - a piece of code and variables local to it,  that corresponds to a
step (e.g. start,   end, main loop, interruption,  recovery,  ...)  of an
algorithm  (servo-loop,   monitoring,  computing,   ...) and    which  is
designated for execution by an execution  engine. The return code (state)
of  the codel enables the  execution engine to make  decisions  as to the
designation  of the next codel for   execution.
Codel's execution should never be interrupted by the execution engine and
are, in this sense, atomic. It is important to stress that this atomicity
must hold only  within a component; the  operating system can preempt the
codel by  scheduling  of  other components, or   other  threads within  a
component.


Herman Bruyninckx wrote :
| Execution engine (also known as: task execution control, task
| sequencing):  the infrastructure software that takes care of the
| proper execution of a given task, within the context of some
                              ^^^^
I would have said 'service' here. Task are - in my mind - much the same
as threads (e.g. VxWorks has tasks, not threads).

| state-based task sequence (Finite State Automaton; Petri Net;
| Hierarchical State Machine; StateCharts; ...). Each state has a codel
| that contains the basic functional part of the task in that state, and
| some auxiliary functions, that implement what must be done at state
| entry and state exit.
| The execution engine helps, for example, to implement controllers that
| have to switch their control algorithms on-line (e.g., in the control
| of a walking device).

Cezary Zielinski wrote :
| EXECUTION ENGINE - a part of the component that is an automaton that
| designates codels for execution. It decides which codel to execute next by
| considering the return values of previously executed codels and the state of
| the data base of the component.

Again, both definitions are fine (with s/task/service/ for Herman's
definition). We can also replace 'database' by 'internal data
structure'. So this could give:

EXECUTION  ENGINE -  active module that  is part  of a component.  It can
spawn threads (or tasks) and it is the infrastructure software that takes
care of the proper  execution of a set  of  services, by implementing  an
automaton that execute the codels corresponding to those services (Finite
State  Automaton;  Petri Net;  Hierarchical State   Machine; StateCharts;
...). Each  state has a codel that  contains the basic functional part of
the  service in  that state;  the   return value  of  codels define   the
transitions between states.
The  execution engine should  also  provide  an internal  data structure,
which represents  the global state of  a component (e.g. current value of
services parameters).
Execution engines are generic modules that can (should!) be reused for
different components.

We might need one more iteration to converge, I guess :)