Re: ipc.pdf ... some remarks

Herman Bruyninckx wrote:

> On Thu, 20 Jun 2002, Christian Schlegel wrote:
>
> > "ipc.pdf" proposal and because I am not yet sure that I got everything
> > right I send you this email on your private account.
>
> That's exactly what mailinglists are for :-)
>
> > Many of the concepts described in your paper are exactly what is inside
> > my communication patterns. Therefore, I assume that you are still
> > compatible with my communication patterns, right ?
>
> I describe a lower-level implementation, that should be compatible
> with _any_ IPC. (If that is not the case, then something is wrong :-))
> And the goal is to maybe come to a core library that many other Orocos
> libraries could use...

Ok, but at this level it might be interesting to check if there are any parts
which are not compatible with middleware like CORBA. If yes, that is an
important topic to talk about ...

> > I however got the impression (when browsing your proposal) that you are
> > concerned very much about various handlers and registering callback
> > methods. Is that the same what is described in my design document on the
> > various interfaces at the level of the framework user ?
>
> I want to describe _mechanism_ (what should be the lowest level
> functionality_; your communication patterns are _policy_ (how should
> one use a specific functionality).

Ok, mechanism and policy are sometimes difficult to differentiate since I do
not want to implement all kinds of mechanisms which might be needed but are
not yet needed. So sometimes the tradeoff is to implement only those
mechanisms which are needed for a specific policy. But of course the overall
mechanisms should fit together in a coherent way.

> > What I do with the communication patterns is to avoid that every
> > consumer registers a callback method at the producer side because
> > then you have strong dependencies between producer and consumer.
>
> Indeed: this is a _policy_ (and one that you can defend with very good
> arguments!). So, I don't want to suggest that all applications should
> use all the mechanisms that I describe. On the contrary. But I tried
> to describe those mechanisms that can support _any_ policy we will
> need in Orocos. That might of course be a bit too ambituous, of
> course:-)
>
> > Where I got confused is
> > which thread executes which part of the various handlers (section 3.2).
>
> At the level I worked in the document, the choice (policy) about which
> thread does what is not yet relevant. Everything can be in one single
> thread even (we have a motion control application that does just
> that);

Ok, I see.

> > If you look at my UML diagrams you can see that there is a clear
> > distinction between the user thread, the communication activity etc.
> > which allows you to provide various user interfaces like callbacks with
> > handlers or blocking calls etc. without ever blocking communication (by
> > the way that is the main issue with respect to avoiding deadlocks).
>
> I again think this is a very defendable _policy_, which is not in
> contradiction with what I describe at the mechanism level. (I think.)
>
> > Another point is the "guard" (section 4.1.1). I use a guard at the
> > producer side of an event to decide whether the event should fire. The
> > guard itself belongs to the event but the parameters for its activation
> > check are send by the event activation. This allows one e.g. to get an
> > event if an activation specific set of parameters gets true. This is
> > very convenient for events !
>
> This is an important architectural design issue! We here in Leuven
> all think that guards are to be avoided: if you need them, that is a
> signal that the event object has one or more internal states, and
> bringing this outside of the mediator object is not a good idea.
>
> Can you give an example of where you need a guard?
>

Very simple example: An event pattern is used to report on the battery
voltage. Therefore the producer of the event reads the battery voltage
regularly and has to decide when to fire the event. It now might have various
components which have to be notified on specific voltage levels. Activating
the event from the consumer includes the voltage threshold. Each event
activation now provides its own set of parameters used in the check method at
the producer side. The check method at the event producer can be seen as a
guard. The event therefore provides a valve which prevents it from firing if
the voltage level for a specific event activation is still high enough. It
only fires if the voltage drops below the threshold. Since an event allows
for many consumers all with their own parameters you get only your event if
the event condition is met under your parameters.

>
> > Boris and I sent a draft on hierarchical state machines to the mailing
> > list some weeks ago. Have you looked at it ? What do you think ?
>
> I still have to study it! Shame on me :-(
>
> > So what I would suggest is to explicitly make clear which parts are
> > design decisions at the "internal" part of the framework, which policies
> > are used within communication patterns etc. and which application
> > programmer policies and communication pattern interfaces result from
> > those underlying models
>
> I couldn't agree more with you!:-) The ambition of the document was
> exactly to provide such a common platform to talk about design
> decisions in a terminology that is well-defined and shared by
> everybody.
>
> > (I think we are still compatible and you end up
> > with the proposed interfaces of the communication patterns). If you look
> > at my sources of the CORBA based implementation you can see how the
> > producer / consumer (or client / server) part of the patterns commuicate
> > by calling internal methods of their CORBA representations and how they
> > are decoupled using condition variables. That decoupling e.g. is very
> > important and can be found as policy in your proposal as well.
>
> I fully agree.
>
> Thanks for the fast response! (I haven't even announced the document
> on the mailing list :-) But I still think this discussion is
> interesting for the public.... Let me know if you don't mind if I post
> these messages to the list.

Yes, you can post it ....

Christian



>
>
> Herman

--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------