Re: Simulating OS semaphore behavior

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

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:1gx5jdfxrewj6.19ufu2gqaakge.dlg@xxxxxxxxxxxxx
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
.

Relevant Pages

  • Re: Simulating OS semaphore behavior
    ... entry Wait when Signal'Count> 0 is ... this will cause the signaling task to wait until some task ... The Signal's barrier is open when the Wait's queue is empty. ...
    (comp.lang.ada)
  • Re: Simulating OS semaphore behavior
    ... entry Wait when Signal'Count> 0 is ... this will cause the signaling task to wait until some task calls wait. ... The classical barrier is as follows: ... protected body Barrieris ...
    (comp.lang.ada)
  • Re: Simulating OS semaphore behavior
    ... entry Wait when Signal'Count> 0 is ... this will cause the signaling task to wait until some task ... The Signal's barrier is open when the Wait's queue is empty. ...
    (comp.lang.ada)
  • Re: Do I need a RTOS?
    ... You pointed out the basic idea of having a regular timer (you ... exists and that delta queue insertion is already implemented [to be ... insertdq(SetPinHigh, 150); ... entry from the queue and executes the function. ...
    (comp.arch.embedded)
  • Re: Smart programming languages
    ... Ada has provided this since 1995 through its protected objects. ... The specification for my protected bounded circular queue is: ... A modular type, such as Queue_Index has a range modulo the number ... When a task calls a protected entry, ...
    (comp.programming)