Re: The condition variable test

On Apr 20, 10:50 pm, Markus Elfring <Markus.Elfr...@xxxxxx> wrote:
The main issue what you should understand is that the wait operation
of the condition variable can return right after the moment you call it.

Advanced synchronisation programmers are used to the wait loop for the handling
of spurious wakeups.

They simply have to use wait loop, they have no other choice, and not
only because the spurious wakeups. They have to use waiting loops
because what they are waiting for is the boolean expression to become
true and not any signal on the condition variable. So simple is that.

Besides, they must comply to the condition variable test too.

Higher level software libraries can make this
implementation detail easier and safer for monitors.

No question they can. However, they must themselves comply to the
test.

The message here is again that you cannot use the condition variable
so that you signal an event from one thread and await the signal in
another thread. You can use a semaphore that way but not any condition
variable.

Do not forget, the condition variable is not designed for that.

I would prefer further clarification from your view what can not be done by the
functions "pthread_cond_signal" or "pthread_cond_broadcast" in comparison to the
function "sem_post".

I am afraid I have clarified clear enough. You must try to follow.

Anyway, you can find a clear example about what cannot be done here:
http://groups.google.com/group/comp.programming.threads/msg/fc06ff81b98a9823

It is just surprising how many of you support the wrong usage and
attack me who highlights the problem. It is also amazing that you are
not able to follow simple working examples.

Best Regards,
Szabolcs
.

Relevant Pages

  • Re: The condition variable test
    ... Advanced synchronisation programmers are used to the wait loop for the handling of spurious wakeups. ...
    (comp.programming.threads)
  • Re: The condition variable test
    ... Advanced synchronisation programmers are used to the wait loop for the handling of spurious wakeups. ...
    (comp.programming.threads)
  • Re: [PATCH 1/2] Futex minor fixes
    ... Changed code to loop in this case. ... what could that spurious wakeups be? ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Is There a Slicker Way?
    ... And I asked for clarification on that advice, but no clarification was forthcoming. ... AND dateadd(DAY, @Days, StartDate) ... I very much appreciate another example, especially if it will eliminate my loop. ...
    (microsoft.public.sqlserver.server)
  • Re: [PATCH] iSeries virtual disk
    ... >> I think that logic needs some clarification. ... - now to that loop in module_init: ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)