Re: Protected Entry Call Semantics

[JP Thornley <jpt@diphi.demon.co.uk>]

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