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

To me the reworked definitions are fairly clear now.

I understand that a codel has a single thread of execution. I gather that
codels can be designated by the execution engine to be executed
concurrently, thus there is no necessity to have separate threads within
codels. One of those mechanisms is more than sufficient.

Cezary

----- Original Message -----
From: "Anthony Mallet" <[email protected]>
To: <[email protected]>
Sent: Friday, February 08, 2002 5:50 AM
Subject: Re: [Orocos] 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 :)
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos