From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.bbs-scene.org!xmission!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail
From: Robert A Duff <bobduff@shell01.TheWorld.com>
Newsgroups: comp.lang.ada
Subject: Re: Ada advocacy
Date: Thu, 29 Aug 2013 11:46:18 -0400
Organization: The World Public Access UNIX, Brookline, MA
Message-ID: <wcceh9czeid.fsf@shell01.TheWorld.com>
References: 
 <19595886.4450.1332248078686.JavaMail.geo-discussion-forums@vbbfy7>
 <2012032020582259520-rblove@airmailnet> <jkc59a$hs5$2@speranza.aioe.org>
 <12ee9bc5-3bdf-4ac0-b805-5f10b3859ff4@googlegroups.com>
 <vhcvr8d4kq6ribdqeeb0b857ei5aa5luiv@4ax.com>
 <6c58fae4-6c34-4d7a-ab71-e857e55897c0@x6g2000vbj.googlegroups.com>
 <wccvc5b49yc.fsf@shell01.TheWorld.com> <op.w2g9br0kule2fv@cardamome>
NNTP-Posting-Host: shell01.theworld.com
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: pcls7.std.com 1377791178 4353 192.74.137.71 (29 Aug 2013 15:46:18
 GMT)
X-Complaints-To: abuse@TheWorld.com
NNTP-Posting-Date: Thu, 29 Aug 2013 15:46:18 +0000 (UTC)
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix)
Cancel-Lock: sha1:79/TIft1U2F1gnebUqLs57J2CtM=
X-Original-Bytes: 2898
Xref: number.nntp.dca.giganews.com comp.lang.ada:183217
Date: 2013-08-29T11:46:18-04:00
List-Id: <comp.lang.ada>

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> Why did you said “no big loss” about the rendez‑vous?

Here's an example based on something Tucker showed me that helped
convince me of the merits of protected objects over rendezvous:

    protected P is
        entry E1(...);
        entry E2(...);
    private
        State: Enum := This_State;
    end P;

    protected body P is
        entry E1(...) when State = This_State do
        ...
        end E1;

        entry E2(...) when State = That_State do
        ...
        end E2;
    end P;

In task T:

    select
        P.E1(...);
    else
        ... -- (***)
    end select;

P is always in one of two states: willing to do E1, and willing
to do E2.  At (***), we know that at the moment P.E1 was called,
P was not willing to do E1, and was therefore willing to do E2.
It is impossible for P to be in a state where it is not willing
to do either E1 or E2.  (A state visible to clients, I mean.)

It's not easy to program that using rendezvous.  The passive
task has to (actively) loop back around to the select statement,
so there is a small window of time where neither 'accept' is
open.  Small windows of time lead to subtle race conditions.

So you end up adding yet more task(s) to implement simple things
like locks.  So using rendezvous tends to add complexity to
the program.

Using an active entity (a task) to program something that
should be passive (which is what you end up doing with
rendezvous) is an abstraction inversion.  It's like killing
a gnat with a sledge hammer.

- Bob