§32.1–32.2What Types Of Bugs Exist? … Non-Deadlock Bugs

Before diving into deadlock, it helps to know the patterns real concurrency bugs take — the first step to writing robust code.

32.1 What Types Of Bugs Exist?

Lu et al. studied concurrency bugs found and fixed in four mature open-source applications — a rare quantitative look at what actually goes wrong:

The headline: non-deadlock bugs are the majority (74 of 105). We look at those first, then deadlock.

32.2 Non-Deadlock Bugs

Lu found two dominant patterns — together ~97% of non-deadlock bugs.

Atomicity-violation bugs

A sequence of accesses the programmer assumed was atomic gets interrupted. The MySQL example (Fig 32.2):

// Thread 1
if (thd->proc_info) {
    fputs(thd->proc_info, ...);
}

// Thread 2
thd->proc_info = NULL;

Thread 1 checks the pointer, then uses it — assuming nothing changes in between. But it can:

Formally (Lu): “a code region is intended to be atomic, but the atomicity is not enforced during execution.” This is an atomicity violation atomicity violation A non-deadlock concurrency bug where a sequence of accesses assumed to be atomic is interrupted, letting another thread interleave and break the assumption — e.g. one thread checks a pointer is non-NULL and is interrupted before using it while another sets it NULL, causing a crash. Fixed by holding a lock around all the accesses. With order violations, ~97% of non-deadlock bugs (Lu et al.). defined in ch. 32 — open in glossary . The fix is usually simple — hold a lock around every access to the shared field (Fig 32.3):

pthread_mutex_t proc_info_lock = PTHREAD_MUTEX_INITIALIZER;

// Thread 1
pthread_mutex_lock(&proc_info_lock);
if (thd->proc_info) {
    fputs(thd->proc_info, ...);
}
pthread_mutex_unlock(&proc_info_lock);

// Thread 2
pthread_mutex_lock(&proc_info_lock);
thd->proc_info = NULL;
pthread_mutex_unlock(&proc_info_lock);

Order-violation bugs

The desired order between two accesses is flipped — A should run before B, but nothing enforces it. The Mozilla example (Fig 32.4):

// Thread 1
void init() {
    mThread = PR_CreateThread(mMain, ...);
}

// Thread 2
void mMain(...) {
    mState = mThread->State;
}

Thread 2 assumes mThread is already set. If it runs first, it isn’t:

Formally: “A should always be executed before B, but the order is not enforced.” This is an order violation order violation A non-deadlock concurrency bug where the desired order between two groups of memory accesses is flipped — A should run before B but the order isn't enforced — e.g. a thread uses a variable another thread was supposed to initialize first, hitting a NULL dereference. Fixed by enforcing order with a condition variable (or semaphore). defined in ch. 32 — open in glossary . The fix is to enforce order — a 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 (with a state variable) is the robust way (Fig 32.5):

pthread_mutex_t mtLock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t  mtCond = PTHREAD_COND_INITIALIZER;
int mtInit = 0;

// Thread 1 — after creating the thread:
pthread_mutex_lock(&mtLock);
mtInit = 1;
pthread_cond_signal(&mtCond);
pthread_mutex_unlock(&mtLock);

// Thread 2 — before using mThread:
pthread_mutex_lock(&mtLock);
while (mtInit == 0)
    pthread_cond_wait(&mtCond, &mtLock);
pthread_mutex_unlock(&mtLock);
mState = mThread->State; // now safe

If Thread 2 runs early it waits for the signal; if it runs late it sees mtInit == 1 and proceeds. When order matters between threads, condition variables (or semaphores) come to the rescue.

Because atomicity and order violations together cover the vast majority of non-deadlock bugs, learning to spot these two patterns — and reaching for a lock or a condition variable — prevents most of them. Next: the harder, older problem of deadlock.