Re: Ada advocacy

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"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