Are rendezvous dead?

Are rendezvous dead?

[Anatoly Chernyshev]

Hello, everybody,

I remember, a long time ago I did read a paper entitled like "Rendezvous
are dead. Long live protected object" where it was stated that protected
types are much more convenient for communication between tasks than
rendezvous. And also the rationale dwells mostly upon these types, not
rendezvous.
The question is: are there any practical instances (in Ada 95) when use
of rendezvous is more advantageous than of protected types? In other
words, is it worhty of trying to write the code using only protected
types and completely ignoring rendezvous as possible solution (like the
GOTO operator)?

Thanks in advance,
Anatoly

Re: Are rendezvous dead?

[Dmitry A.Kazakov]

Anatoly Chernyshev wrote:

> Hello, everybody,
> 
> I remember, a long time ago I did read a paper entitled like "Rendezvous
> are dead. Long live protected object" where it was stated that protected
> types are much more convenient for communication between tasks than
> rendezvous. And also the rationale dwells mostly upon these types, not
> rendezvous.

Rendezvous and protected objects are orthogonal views on synchronization: 
procedural and OO-ish, if you want. None can supersede another.

> The question is: are there any practical instances (in Ada 95) when use
> of rendezvous is more advantageous than of protected types? In other
> words, is it worhty of trying to write the code using only protected
> types and completely ignoring rendezvous as possible solution (like the
> GOTO operator)?

If you try to do it for a system of a real size and complexity, you will 
probably end with a kind of obscure emulation of rendezvous using protected 
objects.

Issues to consider are: blocking, parameter passing at 
synchronization points, extensibility, layered protocols.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Are rendezvous dead?

[Pat Rogers]

"Anatoly Chernyshev" <rhezusfactor@yahoo.com> wrote in message
news:3CB940F7.4EC50CFD@yahoo.com...
> I remember, a long time ago I did read a paper entitled like "Rendezvous
> are dead. Long live protected object" where it was stated that protected
> types are much more convenient for communication between tasks than
> rendezvous. And also the rationale dwells mostly upon these types, not
> rendezvous.
> The question is: are there any practical instances (in Ada 95) when use
> of rendezvous is more advantageous than of protected types? In other
> words, is it worhty of trying to write the code using only protected
> types and completely ignoring rendezvous as possible solution (like the
> GOTO operator)?


If tasks require _direct_ communication/synchronization, rendezvous is generally
the right way to go for that specific part of their behavior.  Otherwise,
protected objects are preferable.


--
---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Are rendezvous dead?

[Marin David Condic]

"Pat Rogers" <progers@classwide.com> wrote in message
news:sYfu8.157$h24.105729203@newssvr11.news.prodigy.com...
>
>
> If tasks require _direct_ communication/synchronization, rendezvous is
generally
> the right way to go for that specific part of their behavior.  Otherwise,
> protected objects are preferable.
>
>
There are a variety of Object Oriented design idioms I've run into recently
dealing with Active Objects and how they might communicate with each other.
For a number of these idioms the Ada rendesvous is a simple, direct
representation that would likely be more efficient than cobbling together
the same answer using protected objects (or some other mechanism). For other
idioms, the heavy weight of the rendezvous is the proverbial Brick Outhouse
and often it is harder to do this way. (e.g. a mailbox where you just want
to leave data for another task to process when it gets around to it.) For
the lighter-weight communication and synchronization, protected objects are
a real blessing & improvement over Ada83.

You really want to have both kinds of tools in the toolbox because design
needs vary. I'd see the rendezvous and protected types both being available
to the designer as a major advantage that Ada has over many other languages.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Are rendezvous dead?

[Robert Dewar]

Anatoly Chernyshev <rhezusfactor@yahoo.com> wrote in message news:<3CB940F7.4EC50CFD@yahoo.com>...


> The question is: are there any practical instances (in Ada 95) when use
> of rendezvous is more advantageous than of protected types? In other
> words, is it worhty of trying to write the code using only protected
> types and completely ignoring rendezvous as possible solution (like the
> GOTO operator)?


Not at all, this would be an absurd point of view. Yes, in
some low level instances, the extra efficiency that comes
from using protected objects is worth the kludgy non-orthogonal
definition of this feature (all the business
of potentially blocking objects etc).

But generally from a design and structure point of view,
RV is far superior, for the same reason that CSP is superior to
semaphores (I trust no one will dispute the
latter, though you never know on CLA)

Re: Are rendezvous dead?

[John McCabe]

On 14 Apr 2002 12:52:51 -0700, dewar@gnat.com (Robert Dewar) wrote:

>But generally from a design and structure point of view,
>RV is far superior, for the same reason that CSP is superior to
>semaphores (I trust no one will dispute the
>latter, though you never know on CLA)

Funny you should mention that, but... only kidding :-)

I just thought it might be worth mentioning Occam here which, for
inter-process communication and synchronisation used 'channels', the
semantics of which are similar to the Ada rendezvous. The designers of
Occam used the concepts of CSP very heavily, as it was clearly the
most relevant paradigm(?) at the time. Personally, I haven't seen
anything that would change that.

As far as rendezvous vs protected objects are concerned, the point of
the protected object appears to be to provide a mechanism for shared,
mutually exclusive access to resources. While a rendezvous can be used
to provide a similar mechanism (and, I believe, was often used in
'passive tasks' to emulate such a mechanism), the rendezvous' forte is
direct task to task communication.

Of course I may be wrong.. :-)

Re: Are rendezvous dead?

[Ted Dennison]

Anatoly Chernyshev <rhezusfactor@yahoo.com> wrote in message news:<3CB940F7.4EC50CFD@yahoo.com>...
> The question is: are there any practical instances (in Ada 95) when use
> of rendezvous is more advantageous than of protected types? In other
> words, is it worhty of trying to write the code using only protected
> types and completely ignoring rendezvous as possible solution (like the
> GOTO operator)?

I personally find them complementary, not competative with each other.

What you can now do in Ada 95 is use tasks *only* for those entities
that logically contain their own thread of control, without having to
create a lot of extra fluff tasks.

In a multi-threaded algorithm you generally want to have each task
designated as either a client or a server. There are some exceptions,
but it is usually a very bad idea to make a task that tries to be
both.

So what do you do when, as often happens, you have two servers or two
clients that need to communicate with each other? The obvious solution
is to create a "gender-bender" task that does nothing but act as a
client or server and pass the data along. But a whole new task seems a
bit heavy of a solution for such a simple problem, does it not? In
Ada83 there was no other way, so Ada83 tasking programs tended to have
oodles of tasks. But in Ada 95, all you have to do is create a
protected "buffer" or "queue" to handle the communications.

That brings us to the other issue in Ada83 that caused task explosion:
task-safe data types. To do it right, you'd essentially need a
different task too coordinate synchronization for each and every data
object. In a fairly complex system, that could work out to oodles of
synchronization tasks. With protected objects, we no longer need those
sync tasks.

So as a design issue, I think one should generally do the following:

1) Identify the threads of control in your system.
2) Work out which need to be servers and which need to be clients.
3) Identify your server-server and client-client communications (which
you should try to minimise in step 2), and place buffers/queues
between them.
4) Use tasks with rendezvous to implement your servers and clients,
and protected types to implement all buffers, queues, and other
complex data types that are accessed by more than one task.


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Are rendezvous dead?

[Jim Rogers]

Ted Dennison wrote:

> I personally find them complementary, not competative with each other.


I agree. Each feature still has a valid place in Ada syntax and usage.


> What you can now do in Ada 95 is use tasks *only* for those entities
> that logically contain their own thread of control, without having to
> create a lot of extra fluff tasks.
> 
> In a multi-threaded algorithm you generally want to have each task
> designated as either a client or a server. There are some exceptions,
> but it is usually a very bad idea to make a task that tries to be
> both.


One example of a design needing tasks to be both clients and servers
is a concurrent command and control system. When I was doing robotics
work with Ada we found that much of our design was devoted to
message translation and distribution.  For instance, one control on
the Operator Control Unit was a joystick. That joystick controlled
speed and direction of the robotic vehicle. One joystick message
was distributed among controls for throttle, brakes, steering, and
transmission. Steering messages were customized for the vehicle
type being controlled. Turning a tracked vehicle requires one track
to be stopped (with a brake command) while the other continues
running. This produces a moderate turning diameter. For tight turns
one track is run in a forward direction while the other is run in a
reverse direction, requiring both brake and transmission commands.
Steering a wheeled vehicle simply involves turning the steering wheel.

In the case of the tracked vehicle, the steering task must be a client
to the operator control unit, receiveing a steering message. It must
then translate that steering message into either a combination of
braking, transmission, and throttle control commands, acting as a
server for the braking, transmission, and throttle commands.

Of course, we did use protected objects between our tasks. This
allowed a brake task, for example, to receive its messages from many
other tasks, and process them in a FIFO manner.

Tasks not directly involved in message distribution commonly
communicated using rendezvous.

Jim Rogers

Re: Are rendezvous dead?

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]


"Jim Rogers" <jimmaureenrogers@worldnet.att.net> a �crit dans le message news: 3CBAFB35.40102@worldnet.att.net...
> Ted Dennison wrote:
>
> > I personally find them complementary, not competative with each other.
>
>
> I agree. Each feature still has a valid place in Ada syntax and usage.
>
If you can read french, you'll find a paper on this topic at http://www.adalog.fr/qt5.htm

Note especially that clean termination of a multi-tasks system is much harder with protected types than with rendezvous.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr