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


"Thomas Mang" <a9804814@xxxxxxxxxxxxxxxxx> wrote in message
news:43b302f7$0$12126$3b214f66@xxxxxxxxxxxxxxxxxxxxxx

> 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. But what happens if
> someone else (probably the signaling thread) has the mutex locked in the
> meanwhile? I 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?

Absolutely not. Imagine if it did. About all you could do after calling
the signal function is release the mutex (since, presumably, you already did
all the work you need to do while holding the mutex, that's why you
signalled. So why re-acquire it?

> 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?

Nothing special happens then. That can certainly happen if you signal
without holding the mutex. It's perfectly sane, in fact, it doesn't really
matter. At worst, it will generate a spurious wakeup. However, spurious
wakeups are explicitly allowed by the standard, so you have to tolerate them
anyway.

> 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?

There is no guarantee. That's why you must code a thread to wait ONLY IF
IT NEEDS TO WAIT. This is the most frequent confusion about condition
variables.

> More important, what's the solution to guarantee wait is called before
> signal is sent? In my eyes, there is a rather simple one:
> Before the thread/function containing the signal is called, the mutex
> associated with the condition variable is locked. Then the part containing
> the signal is called. In that part, before the signal is sent the mutex
> will be locked. Therefore, the mutex is guaranteed to be locked before
> other parts of the programm ever get the chance to lock it. During the
> wait-call, the mutex is unlocked. Now I have a waiting thread, and the one
> supposed to send the signal can lock the mutex now and send the signal,
> "transfering" the mutex-lock to the now awakened thread.
> Is that profound? Is that the usual design pattern? Is it usual at all to
> have (as invariant) the waiter waiting before the signal can be sent, or
> are signals without any responding thread (because no one wait) completely
> common?

You are fundamentally misunderstanding how condition variables *must* be
used. A condition variable must be associated with a predicate, and you must
call a pthread_cond_*wait function *only* if you do in fact need to wait for
the predicate.

This is typical:

int ready;

pthread_mutex_lock();
while(ready==0) pthread_cond_wait(..);
// do stuff
pthread_mutex_unlock();

and

pthread_mutex_lock(...);
ready=1;
pthread_mutex_unlock(...);
pthread_cond_broadcast(...);

Now, look closely at the broadcast. That's just in case there was a
thread blocking in pthread_cond_wait waiting for ready to become one. If
there is no thread waiting, it's not an issue, because the thread *will*
*not* *wait* if ready is 1.

DS


.

Relevant Pages

  • Re: [newbie] conditions: signal sent before waiter available?
    ... With a condition variable is a mutex associated. ... In the book, some examples demonstrate condition variables, waiting for signals, sending signals and awakening. ... 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. ...
    (comp.programming.threads)
  • Re: Pthread waiting for two signals??
    ... Thread C must wait for the two signals S1 and S2 to execute. ... You are using condition variables without a predicate. ... Acquire the mutex. ...
    (comp.programming.threads)
  • 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: 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 waiting for two signals??
    ... this because condition variables are stateless. ... Acquire the mutex. ... Set the A predicate to true. ... This approach should reduce the number of mutex acquisitions in the case that both signals are asserted. ...
    (comp.programming.threads)