Re: blocking communication?

Herman Bruyninckx wrote:

> On Wed, 24 Apr 2002 [email protected] wrote:
>
> [...]
> > > 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.
> >

Hi,

I think it is important to get rid of the idea that blocking is per se
dangerous. As soon as you have threads (which nowadays is a standard feature and
the many comfortable classes are available in ACE e.g. which hide OS specific
details) there is no reason why you have to think on blocking another activity
in your component. It simply has to be put into another thread and it simply has
to be synchronized by condition variables or by a message queue or what else if
necessary. It has been necessary to distribute calculations and activities over
several "short running" functions to ensure that a component is reactive but
with threads but every activity into a separate thread if you get the feeling
that it should not be influenced by another activity.

This is the reason why in the SmartSoft component architecture the communication
patterns are in their own thread (the main thread) and why every user activity
is put into at least one separate thread (SmartTaskClass). This makes sure that
in case of the CORBA version, the low-level CORBA communication is running
completely independent of the user thread activites.

Christian

>
> Okay, I see. And I agree with this scenario, except that I would like
> to have a blocking communication, _if_ it can have a time out and/or
> if it can be interrupted by the local `supervisor'. That means, do a
> blocking communication only in a thread on its own: blocking this
> thread is not blocking the whole system, and allows you to use the
> synchronization feature of blocking communication. An example I have
> in mind: a sensor processing routine waits for its next data from the
> sensor device driver in a blocking mode, such that it gets started
> with its processing as soon as the data arrives. If the running task
> doesn't need the sensing processing anymore, there are many possible
> ways to stop the thread of the sensor processing: give it a `data
> message' which contains an abort information; get rid of the thread in
> a brute force way; interrupt it by the supervisor (this is possible,
> if the blocking communication is a condition variable with an `or' of
> blocking on the communication on the one hand and an `abort' condition
> from the supervisor on the other hand.
>
> So, I don't think that blocking communication per se is not dangerous;
> using nothing  but blocking communication in a single threaded
> application that expects each communication to work, however, is not a
> good idea. And I guess that's what you meant?
>
> Herman
> --
> K.U.Leuven, Mechanical Engineering, Robotics Research Group
> <http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480
>
> _______________________________________________
> 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/
---------------------------------------------------------------------