Re: Question for the folks who designed Ada95

[Robert Dewar <robert_dewar@my-dejanews.com>]

In article <7g4rof$42c$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:

I quite realize that Ted's post was intended to be jokes
and I appreciate it as that, but one interesting serious
issue is raised.


> Why do we call tasks "task" when they are really threads?
> That's confusing.

In fact the idea of the original design was that task is
a much higher level concept, and that whether a given task
is implemented as a thread is an implementation detail.
Most certainly the expectation was that some tasks would
not be threads at all. Consider this example from the Ada
83 RM:

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.

The objection to this was not so much technical as
conceptual. I remember one person at a RTWG meeting saying
"I don't care what you say, a task is a thread, and nothing
you can say will make me change that opinion".

Given this unshakable view of what a task is, then you
can see that the notion of abstraction inversion (it is
silly to implement locks in terms of threads) is a strong
argument.

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.

What happens in practice is that people ignore this, and
either through  illicit knowledge of what is in bodies, or
through shear luck, they avoid blocking calls.

A much worse outcome -- very common in practice -- is that
people DO blocking calls, and they work just fine, because
the protected records are implemented with general locks.
FOr most implementations the restrictions against
potentially blocking operations are totally unnecessary.

Indeed these restrictions are only there to serve the needs
of high efficiency bare board implementations, and often
have little relevance to implementations over operating
systems.

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!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own