RE: blocking communication?

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