Re: Simulating OS semaphore behavior

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

On Sat, 26 Aug 2006 13:34:50 GMT, REH wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1gx5jdfxrewj6.19ufu2gqaakge.dlg@40tude.net...
>> On Fri, 25 Aug 2006 19:31:53 +0200, Jean-Pierre Rosen wrote:
>>
>>> Dmitry A. Kazakov a �crit :
>>>> That looks like a classic automatic event for multiple tasks. Make 
>>>> Signal
>>>> an entry:
>>>>
>>>>    protected body Event is
>>>>       entry Wait when Signal'Count > 0 is
>>>>       begin
>>>>          null;
>>>>       end Wait;
>>>>       entry Signal when Wait'Count = 0 is
>>>>       begin
>>>>          null;
>>>>       end Signal;
>>>>    end Event;
>>>>
>>>> Signal is blocked until all waiting tasks get released. There is no race
>>>> condition because fresh attempts to Wait are blocked if a signal is
>>>> pending.
>>>
>>> However, this will cause the signaling task to wait until some task
>>> calls wait.
>>
>> Why? The Signal's barrier is open when the Wait's queue is empty.
>>
>> Surely there are subtleties with the above:
>>
>> 1. The same task might get the same event twice if it anew queues itself 
>> to
>> Wait before emptying the queue.
> 
> I want to avoid this.
> 
> How about:
> 
> protected type Event is
>     entry Wait;
>     procedure Signal;
> private:
>     Arrived : Boolean := False;
>     entry Wait_More;
> end Event;
> 
> protected body Event is
>     entry Wait when not Arrived is
>         requeue Wait_More;
>     end Wait;
> 
>     procedure Signal is
>     begin
>         Arrived := True;
>     end Signal;
> 
>     entry Wait_More when Arrived is
>         Arrived := Wait_More'Count > 0;
>     end Wait_More;
> end Event;

It is the "lounge" pattern, which, as well, can be done without the Arrived
state. But that's rather a matter of taste.

The problem of this thing is: when the tasks are on the move from the
waiting room (Wait) to the service room (Wait_More), and amidst of this,
Signal gets called, it will shut the door before those unfortunate, who
hadn't yet managed through. The effect is that they will miss the event,
though they had been queued *before* the event happened.

An aside rant: You should carefully analyze your requirements, because an
"ideal" synchronization object just does not exist. In general, when the
publisher-subscriber relation is not DAG, 100% delivery and absence of
deadlocks are mutually exclusive. The requirements: no order inversions, no
ghosts, no misses are all contradictory. And event is a too low-level
thing, you'll probably never be satisfied with it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de