Re: blocking communication?

[email protected] wrote:

> > -----Original Message-----
> > From: Herman Bruyninckx [mailto:[email protected]]
> > Sent: Wednesday, April 24, 2002 9:11 AM
> > Cc: Open RObot COntrol Software
> > Subject: Re: [Orocos] blocking communication?
> >
> >
> > On Wed, 24 Apr 2002 [email protected] wrote:
> >
> > > I am a PhD student of the TU-Vienna. I followed the last
> > discussion about
> > > communication and configuration (states, interupts, ...) with high
> > > attention. For me a simple question arises:
> > > Why do you use blocking communication patterns?
> >
> > The blocking could be useful as synchronization.
> >
> > > Isn't it better to use only non-blocking communication,
> > because it enables a
> > > seperation of communication and configuration?
> >
> > Why can't one separate configuration and blocking communication?
>
> Maybe 'configuration' (especially gerneral configuration as mentioned in
> Henriks answer) was the wrong term. I try to explain the
> communication-configuration-link with the following example:
> Assume a blocking query (consits of query-request & query-answer). When the
> query-request is already sent out, the query-request sending component is
> blocked (waiting for the query-answer). If the query-request sending
> component has to be reconfigured during this time it is blocked! Hence a
> 'special' communication (=communication-configuration-link) has to be
> implemented to interrupt the blocking communication in such a situation.
> I got the impression that the Communication Pattern of Smartsoft exactly
> deals with this point.
>
> Wolfgang

Hi Wolfgang,

Yes, the SmartSoft state pattern (formerly called "configuration") does
exactly this and it is already implemented in the CORBA based version. If you
are interested in this, you can get the sources.

However, there are various kinds of interfaces like blocking ones and
non-blocking ones. Of course, it is sufficient to have only one but it depends
on the structure of your component which one fits best your needs. Therefore,
many patterns provide both kind of interfaces, namely blocking and
non-blocking. In my view, you are absolutely right, that the blocking
interface needs the state pattern to abort blocking waits. However, I don't
see any disadvantage since there are reference implementations dealing with
this fundamental problem. Since the patterns are in use for several years now,
those combinations survived which are most useful. There is absolutely no
reason, why one should not provide another set of methods extending the
patterns by an interface needed at some time. The pattern structure contains
nothing which would cause problems since e.g. sending and receiving a request
are completely decoupled and synchronized internally by condition variables
(This e.g. is an important point when you want to resolve dependencies since
with this implementation every module is at least able to receive its messages
and therefore "removes" them from the client component.).

Again, having blocking calls requires the state pattern but the state pattern
does not conflict with any other internal automaton for configurations etc.
Avoiding blocking calls is in many cases not very intuitive and results in
difficult to read sources since often the clean sequential processing
structure gets distributed over several "callbacks". As soon as you use
threads there is no reason to distribute computation sequences over severall
functions since it doesn't matter that you have a thread being blocked until
it gets its query answer to continue its processing.

Christian


>
>
> >
> > Herman
> >
> >
> > _______________________________________________
> > Orocos mailing list
> > [email protected]
> > http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos
> >
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos

--

---------------------------------------------------------------------
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/
---------------------------------------------------------------------