"Yannick Duchêne (Hibou57)" <yannick...@yahoo.fr
> Why did you said “no big loss” about the rendez‑vous?
That's too big a topic to discuss in the margin of this message. ;-)
Just a few comments:
Protected objects can do almost everything rendezvous can do,
and I find protected objects to be more flexible.
The main thing I miss when using protected objects is the 'terminate'
alternative (as pointed out by J-P). The 'terminate' alt works only
with accept statements, not with entry calls. Also, you can do
multi-way waits with accept statements but not entry calls.
These things are a loss, but not a "big" loss. These limitations
of protected objects could be fixed, and then rendezvous would
be truly superfluous.
Suppose I have task A that wants to communicate with task B.
When programming in Ada 83, I usually found myself adding
another "passive" task in between A and B. Passive tasks
look something like this:
accept E (...);
It just feels wrong to me for that to be a task. It's not
really doing anything; it's just sitting around waiting
to be told what to do -- like a protected object.
The "do stuff" above is likely some simple action
like putting data in a queue or taking it out.
A protected object seems better for that -- perhaps it's
"lower level", but it's the RIGHT level. And with a protected
object, you don't need a 'terminate' alternative in this case
-- protected objects just go away like any passive object
(say, an integer).
With rendezvous, one of the tasks must know about the other
(i.e. know its name), which increases coupling.
One ought to be able to split out pieces of code into
separate procedures -- that's an important tool for abstraction.
Any language design that inhibits that is questionable, IMHO.
As has been mentioned, accept statements must be lexically
within the task body, which damages this capability.
Rendezvous is a hugely complicated mechanism, which leads to
bugs, not to mention inefficiencies.