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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ab549d7e16193bf7
X-Google-Attributes: gid103376,public
From: Brian Nettleton <bn@aonix.com>
Subject: Re: ATC---The Holy Grail of Ada Tasking?
Date: 1998/07/08
Message-ID: <35A2C41D.F22CAE9E@aonix.com>#1/1
X-Deja-AN: 369408148
Content-Transfer-Encoding: 7bit
Sender: news@sd.aonix.com (USENET News Admin @flash)
X-Nntp-Posting-Host: stout
References: <slrn6p3tph.q9p.franke@paxp01.mipool.uni-jena.de>
To: Frank Ecke <franke@paxp01.mipool.uni-jena.de>
Content-Type: text/plain; charset=us-ascii
Organization: Aonix
Mime-Version: 1.0
Reply-To: bn@sd.aonix.com
Newsgroups: comp.lang.ada
Date: 1998-07-08T00:00:00+00:00
List-Id: <comp.lang.ada>

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