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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7001494ace46eea7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-23 14:18:09 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: adam@irvine.com (Adam Beneschan) Newsgroups: comp.lang.ada Subject: Re: Overriding discriminants perplexes GNAT 3.14p Date: 23 Sep 2002 14:18:08 -0700 Organization: http://groups.google.com/ Message-ID: References: NNTP-Posting-Host: 66.126.103.122 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1032815889 10214 127.0.0.1 (23 Sep 2002 21:18:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Sep 2002 21:18:09 GMT Xref: archiver1.google.com comp.lang.ada:29293 Date: 2002-09-23T21:18:09+00:00 List-Id: Dmitry A.Kazakov wrote in message news:... > Adam Beneschan wrote: > > See http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00148.TXT?rev=1.2 > > for the official word on the matter. > > Maybe I have missed something, it is a rather lenghty document, but it only > clarifies a rather obvious idea that an external requeue should be made in > a safe way to avoid race condition. So the original protected action > lingers for awhile until requeueing is done. Here's what it actually says, right up front: "The requeue of a protected entry to an entry in another protected object requires the protected action resulting from the requeue to be completed before the original protected action completes". When an external requeue is made to an open entry, 9.5.4(11) says that a protected action is started on the target object and proceeds as for a normal entry call. If the entry is open (as in your example code), the protected action consists of executing the entry body and servicing the entry queues, and then the protected action is complete (9.5.3(8,10,18)). If the entry is closed, the entry call (i.e. the one caused by the requeue, in your code) is queued, and the protected action completes. The summary of AI-00148, which I quoted above, says that when an entry in protected object P1 does a requeue to protected object P2, the protected action on P2 must be completed (including, if the entry in P2 is *open*, executing the body of that entry and processing any other queued calls in P2 that can now execute) before the protected action on P1 is completed. In other words, they nest. Note that the protected action does *not* include waiting on a queue. If the external requeue is to an entry whose barrier is closed, the nested protected action queues the entry and then is complete, allowing the protected action on the first protected object to complete. The protected action on the requeueing object does *not* remain in effect indefinitely until the barrier becomes open. It completes as soon as the requeued entry call gets put on the queue. This could be the source of your misunderstanding. > Does it say that the protected action continues and locks the original > object until any consequent protected action and actions it in turn might > invoke complete? Yes. > It would a disaster. Consider a protected object serving as a scheduler. It > routes requests via requeue to numerous other protected objects and tasks > that would then serve the requests. It would be simply impossible to do > that if the scheduler would remain locked until a request is finally served > by another object or task. See above. I have a feeling this is due to your misunderstanding of what happens in the "protected action" when a requeue is to a closed entry. -- Adam