Re: Overriding discriminants perplexes GNAT 3.14p

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On 23 Sep 2002 14:18:08 -0700, adam@irvine.com (Adam Beneschan) wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<amil7u$6897n$1@ID-77047.news.dfncis.de>...
>> 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