Re: Overriding discriminants perplexes GNAT 3.14p

[adam@irvine.com (Adam Beneschan)]

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.

				-- Adam