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

On Fri, 8 Feb 2002, Anthony Mallet wrote:

[...]
> I basically agree with the two definitions (which are actually very close
> to eachother).

Ok. Then I put up a fusion of both. Or rather, I'll take Sara's
version.

> [Herman] Just one remark: codels should never make explicit actions to
> make preemption impossible!

I will add this too. But I thought it was possible for a codel to use
a system wide lock, for example to interface some hardware? Otherwise,
if a codel cannot do that, which component can? The device driver?

> Unless someone sees a real need, I propose to limit (at least for 1.0
> design :) to one single state (codel) at a time.

I agree with this.

> 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. 
Ok.

> Task are - in my mind - much the same
> as threads (e.g. VxWorks has tasks, not threads).

Ok, but what about `robotic tasks'? The things we want our robot to
execute are seldom called `services' :-) But I agree that the
codel/execution engine concept is much more general than the robotics
context, so I use `service'.

> | 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:
[...]
I've put this version online.

Herman