Re: [Fwd: Mini meeting Toulouse 22-23 april / Execution Engine]

On Fri, 19 Apr 2002, Christian Schlegel wrote:

[...]
> > The communication patterns form a framework since they assist the
> > component developer and the component user in building and using
> > distributed components in such a way that the semantic of the
> > interface is predefined by the patterns. 

Indeed. This is the clearest description about these things that I've
seen till now. I add it to the glossary on the web page.

> > However, the communication
> > patterns do not help the component developer in structuring the
> > internals of a component. However, communication is related to the
> > internal component structure since the communication patterns provide
> > blocking calls which must be interruptable independently of what the
> > component developer is doing inside his component. 

Your ``is related to'' I would rephrase as: ``supports the
specification and implementation of''.

> > The configuration class provides a thread level activity control and
> > leaves it to the user what he is doing inside his threads as long as
> > he uses the configuration class to lock / unlock states in critical
> > blocks. 

I see (I think). But the name ``configuration class'' seems a bit odd
or too general to me. 

> > Methods to set states, to abort locked states and
> > pending communication calls etc. are all provided in the configuration
> > class.

That's what I thought would be in the ``configuration class''. We've
discussed a bit here about how to call it `correctly' but we don't
find a more appropriate name... I do think the ``execution'' would be
part of the name, because what one does is to influence what a
certaint component/thread is doing at a given moment, and will be
doing at the next moment. So, ``execution configuration'' is more
appealing to me. 

> > This now is exactly the place where Genom provides another approach.
> > As far as I understand, the user does not put its calculations and
> > activities into several interruptable threads (as in SmartSoft) but
> > splits calculations / activities into codels. The execution engine of
> > Genom now organizes the different codels in such a way that various
> > criterions like interruptability etc. etc. are ensured. I can imagine
> > that the Genom approach is better suited for components where one has
> > to meet realtime constraints since the Genom execution engine gives
> > you probably much more control on the way how codels are interleaved.

Why should Genom be better suited for these purposes?

> > The SmartSoft approach is not as fine grained and seems to be easier
> > applicable if you have more time intensive calculations (even cyclic
> > calculations) which you do not want to split into several codels.

Where does the granularity of your activity shows up in the patterns?
Or in Genom?  Nowhere, I think...

> > The difference between the SmartSoft and the Genom view therefore is
> > the level of assistance and comfort (and therefore of course the level
> > of constraints) to structure the activities within a component. Both
> > approaches have the same goal, namely ensuring specific demands on the
> > behavior of a component. Even though both approaches are very similar
> > they follow a different programming paradigm influencing the way a
> > component developer has to think on the internal activities of his
> > component.

I would like to understand better what you mean... Or I fail to
understand the real meaning (or you fail to explain it to me:-), or
there is no _fundamental_ difference between both approaches, only
differences in terminology.

> > Completely independent of that level is the task execution level. Of
> > course, one can use finite state automatons to control complex task
> > sequences, it is often not very convenient do this since exception
> > handling etc. is very troublesome if you have to expand every possible
> > state sequence into the automaton. 

Can you give an example?

> > Therefore task nets (which are
> > interpreted and can therefore be expanded depending on the current
> > knowledge about the environment etc.) are much more suitable at this
> > level. 

What is the difference with hierarchical state machines? (Where a
transition brings you to a new state, which is in fact an FSM in its
own, but about whose internals the external states don't want to
know.)

Herman

-- 
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480