Re: Question for the folks who designed Ada95

[Robert A Duff <bobduff@world.std.com>]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> Example of task specification and corresponding body:
> 
>     task PROTECTED_ARRAY is
>        --  INDEX and ITEM are global types
>        entry READ (N : in INDEX; V : out ITEM);
>        entry WRITE(N : in INDEX; E : in  ITEM);
>     end;
> 
>     task body PROTECTED_ARRAY is
>        TABLE : array(INDEX) of ITEM := (INDEX =>
>                                           NULL_ITEM);
>     begin
>        loop
>           select
>              accept READ (N : in INDEX; V : out ITEM) do
>                 V := TABLE(N);
>              end READ;
>           or
>              accept WRITE(N : in INDEX; E : in  ITEM) do
>                 TABLE(N) := E;
>              end WRITE;
>           end select;
>        end loop;
>     end PROTECTED_ARRAY;
> 
> The intention was most certainly that this be implemented
> without a separate thread, using an approach similar to
> the protected records of Ada 95, and indeed several Ada
> 83 compilers including DEC Ada and Verdix implemented
> "passive" tasks in this manner.
> 
> There was a minority thread of opinion in the Ada 95 design
> (notably held by Paul Hilfinger and me) that the whole
> business of protected records was a mis-step, and that a
> better approach would have been to formalize the notion of
> a passive task.

One of the things that convinced me you and Paul were wrong is to
consider the semantics of a conditional entry call, eg:

    select
        PROTECTED_ARRAY.WRITE(...);
    else
        ...
    end select;

The above task is almost always able to accept a call to Write, but
there are small windows of time during which it won't.  That semantics
seems fishy to me.  For the "equivalent" protected object, you can write
it so that it will *always* be able to accept a call to Write.  Or, in a
different example, you can set things up so that the PO is always in one
of *two* states (able to accept this entry, or eble to accept that
entry), and the transition between states is atomic (that is, callers
can't see the PO in the transitory state).  So a caller could use a
conditional entry call, and know that if the Foo entry isn't available,
the Bar entry must have been.  That kind of semantics seems cleaner to
me.  Contrast with a server task, where there's always a window of time
while the task loops back to the beginning of the selective accept --
and that window is externally visible.  Seems like asking for trouble --
the worst kind of bug, where it only happens once in a blue moon.  And
some implementations might even optimize away the bug.

> I personally do not like the protected types of Ada 95 at
> all. Why not? Because they are abstraction impaired. They
> have all kinds of restrictions that are from a semantic
> point of view nonsense, and which mean that you cannot
> compose them. You can for example call a procedure from a
> protected procedure, but only if it does not do a
> potentially blocking operation. This means that
> conceptually every subprogram, since it might be called
> from a protected procedure, must reveal in its spec whether
> it can do any blocking calls.

I agree somewhat with that criticism.  Nonetheless, I  prefer
using protected objects to using rendezvous.

> Anyway, bare in mind that the above arguments were fully
> presented and explored during the Ada 95 design, and were
> rejected soundly, so they must be wrong!

I don't see a smily.  Minorities (even minorities of one) are often
right!

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.