Introduction to Safe Multithreading in C

Multithreading enables C programs to perform multiple operations concurrently, improving throughput and responsiveness on modern multi-core systems. However, concurrent access to shared data introduces subtle bugs—race conditions, deadlocks, and data corruption—that can crash an application or produce incorrect results. This article provides a practical, authoritative guide to using POSIX mutexes and semaphores for safe thread synchronization in C. You will learn how these primitives work, when to use each, and how to avoid common pitfalls. By the end, you will be able to write high-performance, production-ready multithreaded C code.

Understanding Thread Safety and Race Conditions

A race condition occurs when the behavior of a program depends on the relative timing of thread execution. Without synchronization, two threads may read, modify, and write a shared variable in an interleaved fashion, leading to lost updates and inconsistent state. For example, if two threads increment a global counter without locking, both may read the same value, increment it in their local register, and write back the same result—the counter only increases by 1 instead of 2.

Thread safety means designing code so that concurrent invocations produce correct results regardless of scheduling. Achieving this in C requires explicit synchronization using primitives provided by the POSIX threads (pthreads) library: mutexes (mutual exclusion locks), semaphores (counting semaphores), and condition variables. This article focuses on the first two as foundational tools.

Mutexes: Exclusive Access to Critical Sections

A mutex (short for "mutual exclusion") is a lock that ensures only one thread at a time can execute a critical section—a block of code that accesses shared data. In POSIX C, mutexes are of type pthread_mutex_t. Here’s the standard lifecycle: initialize, lock, access critical section, unlock, destroy.

Basic Mutex Usage

#include <pthread.h>
#include <stdio.h>

pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
int shared_counter = 0;

void* increment_thread(void* arg) {
    for (int i = 0; i < 100000; i++) {
        pthread_mutex_lock(&lock);
        shared_counter++;
        pthread_mutex_unlock(&lock);
    }
    return NULL;
}

This pattern prevents data races on shared_counter. Each thread acquires the mutex before modifying the variable and releases it immediately afterward. However, locking and unlocking incur overhead—keep critical sections as short as possible to minimize contention.

Mutex Attributes and Initialization

You can create a mutex with specific attributes using pthread_mutex_init() and a pthread_mutexattr_t object. Key attributes include:

  • Type: PTHREAD_MUTEX_NORMAL (default, no deadlock detection), PTHREAD_MUTEX_RECURSIVE (allows same thread to lock multiple times), PTHREAD_MUTEX_ERRORCHECK (returns error on double-lock by same thread).
  • Robustness: PTHREAD_MUTEX_ROBUST recovers when a thread holding the lock terminates abnormally.

Example of a recursive mutex:

pthread_mutexattr_t attr;
pthread_mutex_t rec_mutex;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
pthread_mutex_init(&rec_mutex, &attr);
pthread_mutexattr_destroy(&attr);

Recursive mutexes are useful when a function that holds a lock calls another function that tries to acquire the same lock. However, they often indicate poor design—try to restructure code to avoid nested locking.

Common Mutex Pitfalls

  • Deadlock: Occurs when two threads each hold one mutex and wait for the other’s mutex. Avoid by enforcing a consistent lock ordering (always acquire locks A and B in the same order across all threads).
  • Starvation: A thread may be denied access indefinitely if other threads continuously acquire and release the mutex. Real-time and fair scheduling policies can mitigate this, but the default POSIX mutex does not guarantee fairness.
  • Forgotten unlock: Always unlock after critical section; otherwise, other threads block forever. Use error-check mutexes during development to catch double-locks.

Semaphores: Controlling Access to a Pool of Resources

A semaphore maintains a count of available resources. Threads call sem_wait() to decrement the count (if zero, they block) and sem_post() to increment it (waking any waiting threads). In C, the type is sem_t. Semaphores are ideal for managing multiple identical resources, such as database connections or thread pool slots.

Binary vs Counting Semaphores

A binary semaphore has a count of 0 or 1 and can be used as a mutex (but with different semantics—no owner concept). A counting semaphore holds any positive integer. The classic producer-consumer problem uses a counting semaphore for buffer slots.

Semaphore Example: Limiting Concurrent Access

#include <semaphore.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

sem_t pool_sem;

void* worker(void* arg) {
    sem_wait(&pool_sem);
    // Access limited resource
    printf("Thread %ld acquired resource.\n", (long)arg);
    sleep(1); // Simulate work
    printf("Thread %ld releasing resource.\n", (long)arg);
    sem_post(&pool_sem);
    return NULL;
}

int main() {
    sem_init(&pool_sem, 0, 3); // Allow 3 concurrent accesses
    pthread_t threads[10];
    for (long i = 0; i < 10; i++)
        pthread_create(&threads[i], NULL, worker, (void*)i);
    for (int i = 0; i < 10; i++)
        pthread_join(threads[i], NULL);
    sem_destroy(&pool_sem);
    return 0;
}

Semaphore Initialization and Destruction

Use sem_init(sem_t *sem, int pshared, unsigned int value) where pshared is 0 for threads within the same process, non-zero for shared memory between processes. Always call sem_destroy() when done.

Choosing Between Mutexes and Semaphores

CriteriaMutexSemaphore
PurposeProtect a critical section (mutual exclusion)Signal or count available resources
OwnershipLocked by a specific thread; only that thread can unlockNo ownership; any thread can post
ReentrancySupports recursive typesNot applicable
Initial unlockLocked state (must unlock)Can be initialized to any count
Blocking threadsOne at a timeMultiple, up to count

In general, use mutexes for exclusive access to shared data and semaphores for signaling or managing a pool of identical resources. Avoid using a binary semaphore as a mutex because it lacks error-checking for thread ownership and can lead to harder-to-diagnose bugs (e.g., a thread accidentally unlocking another thread's lock).

Advanced Synchronization Patterns

Condition Variables

While mutexes protect data, condition variables allow threads to wait for a specific condition to become true. They are used together with a mutex. The pattern: lock mutex, while condition not met, call pthread_cond_wait() (which atomically unlocks the mutex and blocks); when signaled, reacquire mutex and re-check condition. This avoids busy-waiting.

pthread_mutex_t cv_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
int ready = 0;

void* waiter(void* arg) {
    pthread_mutex_lock(&cv_mutex);
    while (!ready) {
        pthread_cond_wait(&cond, &cv_mutex);
    }
    // Critical section now safe because condition true
    pthread_mutex_unlock(&cv_mutex);
    return NULL;
}

void* signaler(void* arg) {
    pthread_mutex_lock(&cv_mutex);
    ready = 1;
    pthread_cond_signal(&cond);
    pthread_mutex_unlock(&cv_mutex);
    return NULL;
}

Reader-Writer Locks

When a resource is read often but written rarely, a reader-writer lock allows multiple readers simultaneously but exclusive write access. POSIX provides pthread_rwlock_t with functions pthread_rwlock_rdlock, wrlock, and unlock. Use them to improve concurrency in read-heavy workloads.

pthread_rwlock_t rwlock = PTHREAD_RWLOCK_INITIALIZER;

void read_data() {
    pthread_rwlock_rdlock(&rwlock);
    // safe read
    pthread_rwlock_unlock(&rwlock);
}

void write_data() {
    pthread_rwlock_wrlock(&rwlock);
    // exclusive write
    pthread_rwlock_unlock(&rwlock);
}

Best Practices for Thread Synchronization in C

  • Keep critical sections minimal. Only protect the code that accesses shared state. Heavy computation should happen outside the lock to reduce contention.
  • Initialize all synchronization objects before use. For static mutexes, use PTHREAD_MUTEX_INITIALIZER. For dynamic, call pthread_mutex_init and check the return value.
  • Always release locks after critical section. Consider using RAII-style wrappers (in C, via scoped functions or helper macros) to ensure unlock even on early returns or errors.
  • Avoid deadlock by imposing a lock order. If multiple mutexes must be acquired, always lock them in the same sequence across all threads. Document the order.
  • Use error-check mutexes during debugging. Set PTHREAD_MUTEX_ERRORCHECK to detect double-locks and other misuse.
  • Test under heavy contention. Use tools like Helgrind (Valgrind) or ThreadSanitizer to detect data races. Also run with real-time stress tests.
  • Prefer mutexes over binary semaphores for mutual exclusion. The ownership semantics of mutexes make bugs easier to diagnose.
  • Watch out for priority inversion. When a high-priority thread waits on a low-priority thread holding a mutex, the low-priority thread may be preempted by medium-priority threads, causing indefinite delay. Use priority inheritance protocols if supported (e.g., PTHREAD_PRIO_INHERIT mutex attribute).

Performance Considerations

Lock contention is the primary bottleneck in multithreaded programs. Measure and optimize:

  • Granularity. Fine-grained locking (locking small data structures separately) reduces contention but increases overhead and complexity. Coarse-grained locking is simpler but limits concurrency.
  • Lock-free techniques. For specific use cases, atomic operations (C11 stdatomic.h) can avoid locks entirely. For example, use atomic increments for simple counters.
  • Read-copy-update (RCU). In some kernels and libraries, readers can access data with no locks while writers make copies and swap pointers.

Always profile with realistic workloads before optimizing. A lock that is never contended is free.

Real-World Example: Thread-Safe Queue

Combining mutexes and condition variables, here is a simple thread-safe queue:

#include <stdlib.h>
#include <pthread.h>

typedef struct {
    int *buffer;
    size_t capacity;
    size_t head;
    size_t tail;
    size_t count;
    pthread_mutex_t mutex;
    pthread_cond_t not_empty;
    pthread_cond_t not_full;
} queue_t;

void queue_init(queue_t *q, size_t capacity) {
    q->buffer = malloc(capacity * sizeof(int));
    q->capacity = capacity;
    q->head = 0;
    q->tail = 0;
    q->count = 0;
    pthread_mutex_init(&q->mutex, NULL);
    pthread_cond_init(&q->not_empty, NULL);
    pthread_cond_init(&q->not_full, NULL);
}

void queue_enqueue(queue_t *q, int value) {
    pthread_mutex_lock(&q->mutex);
    while (q->count == q->capacity)
        pthread_cond_wait(&q->not_full, &q->mutex);
    q->buffer[q->tail] = value;
    q->tail = (q->tail + 1) % q->capacity;
    q->count++;
    pthread_cond_signal(&q->not_empty);
    pthread_mutex_unlock(&q->mutex);
}

int queue_dequeue(queue_t *q) {
    pthread_mutex_lock(&q->mutex);
    while (q->count == 0)
        pthread_cond_wait(&q->not_empty, &q->mutex);
    int value = q->buffer[q->head];
    q->head = (q->head + 1) % q->capacity;
    q->count--;
    pthread_cond_signal(&q->not_full);
    pthread_mutex_unlock(&q->mutex);
    return value;
}

void queue_destroy(queue_t *q) {
    free(q->buffer);
    pthread_mutex_destroy(&q->mutex);
    pthread_cond_destroy(&q->not_empty);
    pthread_cond_destroy(&q->not_full);
}

This pattern is widely used in multi-threaded applications, from network servers to GUI event loops.

Conclusion

Mastering mutexes and semaphores is essential for writing safe, performant multithreaded C programs. Use mutexes to protect critical sections and semaphores to manage resource pools. Combine them with condition variables for efficient waiting. Always initialize objects, respect lock ordering, and test with race detection tools. For further reading, consult the POSIX specification for pthreads, the Open Group pthread documentation, Linux man pages, and the book Programming with POSIX Threads by David R. Butenhof. By applying these practices, you can build robust, concurrent software that scales with modern hardware.