Protected Entry Call Semantics

Protected Entry Call Semantics

[Stephan Heinemann]

Hi,

regarding entry calls on protected objects that cannot be immediately
selected, i.e., they are closed, the ARM states the following in C.9.5.3
(13,15):

--
When a queued call is selected, it is removed from its entry queue.
Selecting a queued call from a particular entry queue is called servicing
the entry queue. An entry with queued calls can be serviced under the
following circumstances:

[...]

If after performing, as part of a protected action on the associated
protected object, an operation on the object other than a call on a  
protected function, the entry is checked and found to be open.
--

Well, my problem is the "can be serviced" in C.9.5.3 (13). I am using
the Ravenscar profile and there may be only one task waiting on a
protected entry. Other tasks trigger that waiting task by opening the 
associated barrier. Lets say there is one such triggering task that
accesses the protected object twice during its response
(just for example, the same could be done with two tasks, each
triggering once). The first access opens the barrier while the second
one closes it.

Now, some implementations may choose to let the triggering task
execute the protected action of the waiting task and position the
latter after the entry call for its resumption. For other
implementations, the waiting task executes its protected action itself
and therefore it depends on the scheduler whether the waiting task 
may enter the protected object or not , i.e., if a time slice is given
to it or not. For the example given, this would be between the two
triggering tasks.

My problem is to formalise this situation somehow...
Do I need to take a particular implementation to be able to do so?
If yes, does anybody know how ORK/GNAT handles this situation?   
The problem is that even both accesses could open the barrier and
I do not even know which access really triggered the waiting task,
i.e., which values where passed to the waiting task and when.
But how can I tell whether a deadline is missed or not if I do not
even know to which event the response belonged?
Would it be a too hard constraint to allow only at most one
triggering task possessing only one triggering access to a
particular protected object in this case?

Thanks in advance,
Stephan

Re: Protected Entry Call Semantics

[Dmitry A. Kazakov]

On 30 Sep 2003 21:19:15 GMT, Stephan Heinemann
<zombie@cs.tu-berlin.de> wrote:

>Well, my problem is the "can be serviced" in C.9.5.3 (13). I am using
>the Ravenscar profile and there may be only one task waiting on a
>protected entry. Other tasks trigger that waiting task by opening the 
>associated barrier. Lets say there is one such triggering task that
>accesses the protected object twice during its response
>(just for example, the same could be done with two tasks, each
>triggering once). The first access opens the barrier while the second
>one closes it.

>Now, some implementations may choose to let the triggering task
>execute the protected action of the waiting task and position the
>latter after the entry call for its resumption. For other
>implementations, the waiting task executes its protected action itself
>and therefore it depends on the scheduler whether the waiting task 
>may enter the protected object or not , i.e., if a time slice is given
>to it or not. For the example given, this would be between the two
>triggering tasks.

>My problem is to formalise this situation somehow...
>Do I need to take a particular implementation to be able to do so?
>If yes, does anybody know how ORK/GNAT handles this situation?   
>The problem is that even both accesses could open the barrier and
>I do not even know which access really triggered the waiting task,
>i.e., which values where passed to the waiting task and when.
>But how can I tell whether a deadline is missed or not if I do not
>even know to which event the response belonged?
>Would it be a too hard constraint to allow only at most one
>triggering task possessing only one triggering access to a
>particular protected object in this case?

If you want to serialize triggering actions, why do not you implement
this in the protected object? I mean, triggering an action should
bring the object into a state where no further action can be triggered
until the responding task finishes with that. [This would of course
block triggering tasks. To avoid blocking you could use a queue of
trigerring actions etc.]

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Protected Entry Call Semantics

[JP Thornley]

In article <blcs0j$pd9$1@news.cs.tu-berlin.de>, Stephan Heinemann 
<zombie@cs.tu-berlin.de> writes
>Hi,
>
>regarding entry calls on protected objects that cannot be immediately
>selected, i.e., they are closed, the ARM states the following in C.9.5.3
>(13,15):
>
>--
>When a queued call is selected, it is removed from its entry queue.
>Selecting a queued call from a particular entry queue is called servicing
>the entry queue. An entry with queued calls can be serviced under the
>following circumstances:
>
>[...]
>
>If after performing, as part of a protected action on the associated
>protected object, an operation on the object other than a call on a
>protected function, the entry is checked and found to be open.
>--
>
>Well, my problem is the "can be serviced" in C.9.5.3 (13). I am using
>the Ravenscar profile and there may be only one task waiting on a
>protected entry. Other tasks trigger that waiting task by opening the
>associated barrier. Lets say there is one such triggering task that
>accesses the protected object twice during its response
>(just for example, the same could be done with two tasks, each
>triggering once). The first access opens the barrier while the second
>one closes it.
>
>Now, some implementations may choose to let the triggering task
>execute the protected action of the waiting task and position the
>latter after the entry call for its resumption. For other
>implementations, the waiting task executes its protected action itself
>and therefore it depends on the scheduler whether the waiting task
>may enter the protected object or not , i.e., if a time slice is given
>to it or not. For the example given, this would be between the two
>triggering tasks.
>

(I replied earlier from my work address but it doesn't seem to have made 
it out, apologies if this is a repeat.)

I don't think that there is any problem here. During the completion of 
the first protected action of the triggering task all the entry queues 
are serviced (9.5.1(7)), so the waiting task will get past the barrier 
at this point. So the fact that the barrier may become closed later 
isn't going to stop it executing. (If I have understood your question 
correctly.)

Cheers,

Phil

-- 
JP Thornley

Re: Protected Entry Call Semantics

[Stephan Heinemann]

> I don't think that there is any problem here. During the completion of 
> the first protected action of the triggering task all the entry queues 
> are serviced (9.5.1(7)), so the waiting task will get past the barrier 
> at this point. So the fact that the barrier may become closed later 
> isn't going to stop it executing. (If I have understood your question 
> correctly.)

Thank you Phil for the reference in 9.5.1. I again tested the situation 
with a triggering task that opens and closes a barrier without being
preempted by the waiting task. Afterwards the waiting task got 
running, it obtained the value corresponding to the opened barrier. The
waiting task - without being preempted again - accessed the protected
object in its response code and obtained the new value corresponding
to the closed barrier... I just was not sure whether this behaviour
depends on the implementation or not. But now there is a reference I
can rely on.

Again, thanks!
Stephan

Re: Protected Entry Call Semantics

[Martin Dowie]

"JP Thornley" <jpt@diphi.demon.co.uk> wrote in message
news:DchpYxC0lye$Iwsa@diphi.demon.co.uk...
> (I replied earlier from my work address but it doesn't seem to have made
> it out, apologies if this is a repeat.)

Phil, they never do from our newserver! If you want to reply from work
we're best going via a google account (or similar). I forget every now
and again and I can always see my posts listed - but only only at work!

Re: Protected Entry Call Semantics

[Stephan Heinemann]

>         If I understand the situation correctly AND if I recall my books 
> (temporarily unavailable) correctly, it is (was?) implementation 
> independent.

>[...]

You gave the definition for a monitor. If a protected object is 
implemented this way everything is fine...  I was not sure about the
optimisations that certain implemenations could perform... Phil
(another follow up) provided the reference I did not find: The
entry-queues are serviced immediately when the barrier opens.

Thanks,
Stephan