pthread condition variables on Linux, odd behaviour

Do you test for some condition before calling pthread_cond_wait() ? I am asking because, it's a very common mistake : Your process must not call wait() unless you know some other process will call signal() (or broadcast()) later.

concidering this code (from pthread_cond_wait man page) :

          pthread_mutex_lock(&mut);
          while (x <= y) {
                  pthread_cond_wait(&cond, &mut);
          }
          /* operate on x and y */
          pthread_mutex_unlock(&mut);

If your omit the while test, and just signal from another process whenever your (x <= y) condition is true, it won't work since the signal only wakes up the processes that are already waiting. If signal() was called before the other process calls wait() the signal will be lost and the waiting process will be waiting forever.

EDIT : About the while loop. When you are signaling one process from another process it is set on the ''ready list'' but not necessarily scheduled and your condition (x <= y) may be change again since no one holds the lock. That's why you need to check for your condition each time you are about to wait. It should always be wakeup -> check if the condition is still true -> do work.

hope it's clear.

The documentation says that it should work... are you sure it's the same conditional value that the rest of the threads are looking at?

This is the example code from opengroup.org:

pthread_cond_wait(mutex, cond):
    value = cond->value; /* 1 */
    pthread_mutex_unlock(mutex); /* 2 */
    pthread_mutex_lock(cond->mutex); /* 10 */
    if (value == cond->value) { /* 11 */
        me->next_cond = cond->waiter;
        cond->waiter = me;
        pthread_mutex_unlock(cond->mutex);
        unable_to_run(me);
    } else
        pthread_mutex_unlock(cond->mutex); /* 12 */
    pthread_mutex_lock(mutex); /* 13 */


pthread_cond_signal(cond):
    pthread_mutex_lock(cond->mutex); /* 3 */
    cond->value++; /* 4 */
    if (cond->waiter) { /* 5 */
        sleeper = cond->waiter; /* 6 */
        cond->waiter = sleeper->next_cond; /* 7 */
        able_to_run(sleeper); /* 8 */
    }
    pthread_mutex_unlock(cond->mutex); /* 9 */

what the last poster said is correct. the KEY to the whole cond-variable situation working correctly is that the cond-var is NOT signalled prior to it being waited on. its strictly a signal that is to be used when others (single or multiple) are waiting. when no one is waiting, its effectively a NOP. which, btw, is NOT how i believe it SHOULD work, but how it DOES work.

larry

I know that this question is quite old but anyway:

At least on Linux, there is a far better mechanism in the Linux kernel that is comparable to Windows events called "eventfd" (event file descriptor).

Personally, I stopped using POSIX condition variables for the above mentioned reason 'if noone is waiting for the condition, then a signalled condition is just lost'.

You may use eventfds as a reliable mechanism to implement the 'producer-consumer-pattern'. Please check the man page eventfd(2) - there is also a special flag available turning an eventfd in a semaphore-style event (EFD_SEMAPHORE).

Writing to it increments an internal 64bit counter (which is accompanied by a wait queue). Reading decrements it (or zeros it out, depending on the semaphore mode). If it is already zero, waiting is performed. Because this is a normal file descriptor, you can use select, poll or epoll to wait for the event to occur. Very clean and nice kernel implementation!

This works like a rock since 2007 (when the eventfd was added to the Linux kernel). Just forget about POSIX condvars on Linux.