Re: ATC---The Holy Grail of Ada Tasking?

Re: ATC---The Holy Grail of Ada Tasking?

[Robert Dewar]

I must say that referring to the ATC abomination as the holy grail of
Ada tasking seems almost sacriligeous. To me this is one of the worst
features of Ada 95. It introduces significant distributed overhead,
and the burden of making your code abort safe (especially when there
is no way, if you are not using pramga Abort_Defer, a special GNAT
pragma) to conveniently make code abort safe, except encapsulating it
in junk protected records, is FAR too heavy. We have had a few people
try to use ATC extensively, but in most cases they gave up (making
code async abort safe is really a VERY difficult discipline). Unless
you are very careful ATC is asking for non-repeatable troubles in
complex programs.

Re: ATC---The Holy Grail of Ada Tasking?

[Brian Nettleton]

Frank Ecke wrote:
> 
> I am currently trying to plunge into the details of ATC (asynchronous transfer
> of control) in Ada. Please consider the following scenario:
> 
>    Given a task, T, and a protected object, P (which owns an entry, E), let T
> execute the following ATC statement:
> 
>    select
>       P.E(...);
>    then abort
>       -- sequence of statements to be aborted upon completion of P.E
>    end select;
> 
> If the entry call is queued, then the abortable part is executed. If, then, the
> entry call can be accepted, the abortable part *and* the triggering statement
> are executed in parallel. Since T's thread of control is associated with the

It is not true that these are executed in parallel.  RM 9.7.4:6 says
that the abortable_part is never started if the entry call is accepted. 
The abortable_part is only executed if (or when) the entry becomes
queued (or requeued-with-abort).  No need for an extra thread.


> abortable part, another thread of control must be employed to execute P.E
> Accordingly, the Ada Standard allows that ``an implementation may perform the
> sequence of steps of a protected action using any thread of control; it need
> not be that of the task that started the protected action.'' (Section~9.5.3)
> Thus, for example, the thread of control of the main program or that of a
> client task engaged in a rendezvous could be used instead. There is, however,
> a question as to what should happen if all other existing threads of control
> are in use. Does ``... any thread of control ...'' mean that an implementation
> is allowed to introduce a new thread of control that executes P.E? And, if so,
> which entity in our sample program is this new thread of control considered to
> be associated with? Or is it deemed to be anonymous (since it will cease to
> exist when P.E completes)? Of course, since nested ATC is possible, the
> problem can be generalized to any (positive) number of threads of control.
> 
>    I am at the end of my wit and would be grateful if someone could help me
> with this problem (or debunk my misconception).
> 
> Thanks in advance,
> 
> Frank Ecke, franke@minet.uni-jena.de

-Brian Nettleton

Re: ATC---The Holy Grail of Ada Tasking?

[Pat Rogers]

Frank Ecke wrote in message ...

<snip>

>   The point is that I am currently writing a project alfa core in which I
am
>investigating and comparing the concurrency features of Ada, CHILL, and
Java.
>This, however, requires me to scrutinize each and every aspect of
concurrency
>in these languages.


In that case, if you haven't already done so, I strongly suggest you have an
extended look at Burns and Wellings' book titled Concurrency In Ada, second
edition (1998), Cambridge University Press, ISBN 0-521-62911-X.  Every
aspect of the Ada 95 tasking model is covered in great detail.

Re: ATC---The Holy Grail of Ada Tasking?

[Frank Ecke]

On 8 Jul 1998 21:00:03 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

>
> I must say that referring to the ATC abomination as the holy grail of
> Ada tasking seems almost sacriligeous. To me this is one of the worst
> features of Ada 95. It introduces significant distributed overhead,
> and the burden of making your code abort safe (especially when there
> is no way, if you are not using pramga Abort_Defer, a special GNAT
> pragma) to conveniently make code abort safe, except encapsulating it
> in junk protected records, is FAR too heavy. We have had a few people
> try to use ATC extensively, but in most cases they gave up (making
> code async abort safe is really a VERY difficult discipline). Unless
> you are very careful ATC is asking for non-repeatable troubles in
> complex programs.
>


I agree; ATC is a subtle topic and I did not intend to praise it.
Actually, the phrase ``Holy Grail of Ada Tasking'' was meant ironically in 
the sense of ``if you want to live in bliss with Ada Tasking, don't touch that
stuff!''  Sorry for introducing this ambiguity!

   The point is that I am currently writing a project alfa core in which I am
investigating and comparing the concurrency features of Ada, CHILL, and Java.
This, however, requires me to scrutinize each and every aspect of concurrency
in these languages.


Frank

Re: ATC---The Holy Grail of Ada Tasking?

[Frank Ecke]

On 10 Jul 1998 15:14:31 GMT, Frank Ecke <franke@minet.uni-jena.de> wrote:

>
>the sense of ``if you want to live in bliss with Ada Tasking, don't touch that
>stuff!''
>


``... don't touch that ATC stuff!'', of course


Frank