Re: [newbie] conditions: signal sent before waiter available?

Hello Thomas,

Thomas Mang wrote:

<good book>

The first thing is theoretical:
With a condition variable is a mutex associated. (At least under POSIX) the one waiting needs to lock the mutex before calling the wait function, and internally the wait-call unlocks the mutex. When the thread is awakened, the mutex is again locked automatically.

The point is that with that condition variable is not only a mutex, but a condition (a user defined one), often called a predecate is associated. It's not a signal that is fired by one thread and consumed by an othere thread. It's signaled by what ever thread made that condition true and consumed by what ever thread that was able to make that condition untrue.

> But what happens if someone else
(probably the signaling thread) has the mutex locked in the meanwhile?

The awaikened thread have to wait until the mutex gets unlocked and have to check if the signaled condition is still true. If it's not true: fine someone else did the job.

strongly suppose a signal-call automatically unlocks the mutex associated with the condition variable, and immediately locks the mutex again for the awakened thread. Is that correct?

No, that is not needed because condition variables are more robust to missed signals. And what you are asking for might be hard to implement.

What if the mutex is locked by a thread that's not the signaling thread? Is that considered to be misuse of threads, or is it sane programming? What happens then?

If it was a thread looking for new work, it might find the predicate "there is work" to be true without beeing signaled. If that thread "consumes" the "signal" the original waked thread might find not work and go to wait again. So it will cause some overhead but will not cause any harm to the logic used.


The second thing is order:
In the book, some examples demonstrate condition variables, waiting for signals, sending signals and awakening. There is one thing I simply don't get. In the alarm example, the waiting thread (call it w-thread) is created in main. That thread contains a few statements and then a wait-call. In main, after that thread is created is a bunch of other statements, parsing input etc. and then calling a function that sends a signal to awaken the waiting thread.
Now my question:
Where on earth is the guarantee that the w-thread has reached the point where it waits before all the statements in main were executend and the point of execution in the function sending the signal was reached?

The whole point is that a waiting thread is not waiting for a signal from an othere thread but waiting on a predecate to become true, and waiting on whatever thread signaling that this predicate became true. So the usuale pattern to wait for a predicate is to lock the mutex that synchronize the access to the predicate and than check if that predicate is true. If not, wait for it to become true and unlock the mutex.

mfg
Torsten

.

Relevant Pages

  • Re: bizarre timing results
    ... > Are you using signals, or how precisely are you waiting? ... [wait on state changed condition associated with mutex] ... > but you may pay a MESI communications tax. ...
    (comp.os.linux.development.system)
  • Re: [newbie] conditions: signal sent before waiter available?
    ... > With a condition variable is a mutex associated. ... > the one waiting needs to lock the mutex before calling the wait function, ... > signals, sending signals and awakening. ... You are fundamentally misunderstanding how condition variables *must* be ...
    (comp.programming.threads)
  • Re: pthread_cond_wait and testing condition explicitly
    ... void wait_for_0_value { ... The waiting thread has released the mutex while it is suspended (you ... When a thread finally signals cond_broadcast, ...
    (comp.unix.programmer)
  • Re: pthread_mutex_unlock (was Re: sched_yield() makes OpenLDAP slow)
    ... >>> But why does A take the mutex in the first place? ... >> to take a lock that is incompatible with the lock already being held, ... But you can't know if a higher or lower priority process is waiting. ...
    (Linux-Kernel)
  • Re: How can I make an efficient First-Come-First-Serve locking mechani
    ... "Threads that are waiting for ownership of a mutex are placed in a first in, ... > I have considered using a waitHandle, Monitor, or a C# lock statement ... Who will acquire the lock next? ...
    (microsoft.public.dotnet.general)