Re: Protected Entry Call Semantics

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

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