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-24 02:40:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Overriding discriminants perplexes GNAT 3.14p Date: Tue, 24 Sep 2002 11:40:20 +0200 Message-ID: References: NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1032860422 8194866 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:29301 Date: 2002-09-24T11:40:20+02:00 List-Id: On 23 Sep 2002 14:18:08 -0700, adam@irvine.com (Adam Beneschan) wrote: >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. According to your description the scheduler indeed will be *locked* if the entry serving the request is *open* when a requeue to it is made. If the entry is closed then it will not. [It seems that it will not be locked if the entry is of a task]. An excellent pitfall! Then whether a circular requeue is a bounded error or not depends exclusively on the state of barriers! And there is no other way than a requeue to influence the barries of another object from a protected action. Even better! --- Regards, Dmitry Kazakov www.dmitry-kazakov.de