§30.1Definition and Routines

Locks give mutual exclusion mutual exclusion The guarantee that if one thread is executing a critical section, others are prevented from doing so — the property locks exist to provide, and the road back to deterministic output. defined in ch. 26 — open in glossary , but not waiting. Yet threads constantly need to wait for something: a parent waiting for a child to finish (a join() join pthread_join(thread, &retval): block until the named thread completes, optionally collecting its void* return value. Long-lived servers may never join; parallel task programs join to know the work is done. (create-then-immediately-join has a simpler name: a procedure call.) defined in ch. 27 — open in glossary ), a consumer waiting for data to arrive. How should that wait be built?

void *child(void *arg) {
    printf("child\n");
    // XXX how to indicate we are done?
    return NULL;
}
int main(int argc, char *argv[]) {
    printf("parent: begin\n");
    pthread_t c;
    Pthread_create(&c, NULL, child, NULL);
    // XXX how to wait for child?
    printf("parent: end\n");
}

The desired output is parent: begin / child / parent: end. The obvious hack is a shared flag the parent spins on:

volatile int done = 0;
void *child(void *arg) { printf("child\n"); done = 1; return NULL; }
// parent:
while (done == 0)
    ; // spin  ← works, but burns the CPU the whole wait

It works, but the parent wastes CPU spinning. We’d rather put the parent to sleep until the condition comes true, and wake it precisely then.

30.1 Definition and Routines

The answer is the condition variable condition variable The signaling primitive (pthread_cond_t): wait(cond, mutex) sleeps the caller — releasing the mutex while asleep, reacquiring before return — until another thread signal()s. Always called with the lock held; always re-checked in a while loop. The deep treatment arrives with ch30. defined in ch. 27 — open in glossary (CV): an explicit queue threads put themselves on when some state isn’t as desired (by waiting), and that another thread pulls from when it changes that state (by signaling). The idea is Dijkstra’s (“private semaphores”); Hoare named it while inventing monitors. A CV pthread_cond_t c; has two operations (we’ll call them wait() and signal()):

pthread_cond_wait(pthread_cond_t *c, pthread_mutex_t *m);  // sleep
pthread_cond_signal(pthread_cond_t *c);                    // wake one

Notice wait() takes a mutex. The rule that makes CVs work:

• wait() assumes the lock is held when called;
• it atomically releases the lock and puts the caller to sleep;
• when woken, it re-acquires the lock before returning.

That atomic “release-and-sleep” is what prevents a whole class of races. The correct join uses it, with a state variable done:

void thr_exit() {
    Pthread_mutex_lock(&m);
    done = 1;
    Pthread_cond_signal(&c);
    Pthread_mutex_unlock(&m);
}

void thr_join() {
    Pthread_mutex_lock(&m);
    while (done == 0)
        Pthread_cond_wait(&c, &m);
    Pthread_mutex_unlock(&m);
}

Step through the handoff (the parent-first case; the reverse case is easy — if the child runs first, it sets done=1, signals nobody, and the parent’s while (done==0) is simply false, so it never waits):

The same lifecycle as a state machine — drive it and watch a thread move between running, sleeping on the CV, and merely ready:

Why both the state variable AND the lock are essential

Two tempting simplifications each break. Drop the state variable (Figure 30.4): if the child runs first and signals when no one is asleep, the signal is lost; the parent later calls wait() and sleeps forever. The variable done is what lets the parent discover the child already finished.

Drop the lock (Figure 30.5): now the check and the sleep aren’t atomic. Replay the deadly interleaving:

With the mechanism understood, the next section stress-tests it on the classic producer/consumer problem — where a single condition variable turns out not to be enough.