§27.3–27.6Locks … Summary

27.3 Locks

For mutual exclusion over a critical section, the mutex mutex POSIX's lock object (pthread_mutex_t): lock() blocks until the caller holds it, unlock() releases. Must be INITIALIZED (static initializer or pthread_mutex_init) and its return codes CHECKED — the two classic omissions. trylock/timedlock variants exist; mostly avoid them. defined in ch. 27 — open in glossary pair:

int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);

The intended usage is exactly what you’d imagine:

pthread_mutex_t lock;
pthread_mutex_lock(&lock);
x = x + 1; // or whatever your critical section is
pthread_mutex_unlock(&lock);

Semantics: if no thread holds the lock, the caller acquires it and enters; if another thread holds it, the call does not return until the caller has the lock (many threads may be stuck waiting; only the holder should unlock). And yet — that snippet is broken, in two important ways:

Flaw 1 — no initialization. Locks must start with correct values. Either the static way:

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

or the dynamic way (the authors’ usual choice — with a matching pthread_mutex_destroy() when done):

int rc = pthread_mutex_init(&lock, NULL);
assert(rc == 0); // always check success!

Flaw 2 — unchecked error codes. These routines can fail — and an unchecked failure fails silently, potentially admitting multiple threads into your critical section. Minimally, wrap:

// Keeps code clean; only use if exit() OK upon failure
void Pthread_mutex_lock(pthread_mutex_t *mutex) {
    int rc = pthread_mutex_lock(mutex);
    assert(rc == 0);
}

Two more acquisition variants exist — trylock (returns failure if the lock is held) and timedlock (gives up after a timeout). Both should generally be avoided; a few situations — notably dodging deadlock, a coming chapter — make them useful.

27.4 Condition Variables

When one thread must wait for another, 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 :

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_signal(pthread_cond_t *cond);

A CV always travels with an associated lock, held when calling either routine. The two sides of the conversation:

Pthread_mutex_lock(&lock);
while (ready == 0)
    Pthread_cond_wait(&cond, &lock);
Pthread_mutex_unlock(&lock);

Pthread_mutex_lock(&lock);
ready = 1;
Pthread_cond_signal(&cond);
Pthread_mutex_unlock(&lock);

Three details carry all the weight. The lock is held around both state change and signal — that’s what keeps races out of your signaling. Wait takes the mutex because it releases it: the caller goes to sleep and lets go of the lock (imagine it didn’t — how could the signaler ever get in?), then re-acquires it before returning. And the condition is re-checked in a while loop, not an if: some implementations can wake a waiter spuriously spurious wakeup Some pthread implementations can wake a waiting thread when nothing actually changed — which is why the condition is re-checked in a WHILE loop, never an if: treat waking as a hint, not a fact. defined in ch. 27 — open in glossary , so treat waking as a hint that something might have changed — never as a fact.

The tempting alternative — just spin on a flag — has a scoreboard:

If CVs still feel confusing, don’t worry too much (yet) — a whole chapter is coming. Until then: they exist, and this is how and why they’re used.

27.5 Compiling And Running

Include pthread.h; link with -pthread:

prompt> gcc -o main main.c -Wall -pthread

You have now successfully compiled a concurrent program. Whether it works is, as usual, a different matter entirely.

27.6 Summary

Creation and join; mutual exclusion via locks; signaling and waiting via condition variables. You don’t need much else to write robust, efficient multi-threaded code — except patience and a great deal of care. The hard part with threads is not the APIs; it’s the tricky logic of building concurrent programs. Read on.