What You Will Learn

• Why threaded programs need a special compiler flag
• How mutexes protect shared data
• The three classic mutex failure modes
• How condition variables let threads wait for a change of state
• A working producer/consumer style demo you can build and run today

Prerequisites

Building a Threaded Program Correctly

On Linux, POSIX thread support lives inside glibc itself — modern distributions no longer ship a separate libpthread.so as a distinct linkable library the way older systems did, but the historical convention of asking the compiler for threading support still applies and is still required. It is not just about linking a library. The compiler has to change how it generates code so that per-thread state — the most obvious example being errno — gets one private copy per thread instead of a single copy shared by the whole process.

gcc -Wall -pthread -o ep_sync_demo ep_sync_demo.c

Why Threads Need Synchronization

The entire appeal of threads, compared to separate processes, is that they share one address space. Any global or heap variable is visible to every thread in the process instantly, with no IPC mechanism required. That convenience is also the danger: if two threads read and modify the same variable without coordination, the result depends on the exact interleaving of machine instructions the scheduler happens to produce, and that interleaving is not something your program controls.

Threads can opt out of sharing for specific variables using thread-local storage (TLS), declared in modern GCC/Clang with the __thread or _Thread_local storage-class keyword. A TLS variable gets a private instance per thread automatically, which is often the simplest fix when a variable genuinely does not need to be shared.

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

/* One private copy of this counter per thread — no locking needed */
static _Thread_local int ep_local_counter = 0;

void *ep_worker(void *arg)
{
    for (int i = 0; i < 5; i++)
        ep_local_counter++;

    printf("thread %p private counter = %d\n",
           (void *)pthread_self(), ep_local_counter);
    return NULL;
}

For data that genuinely must be shared, Linux gives pthreads two core synchronization primitives: the mutex, for mutual exclusion, and the condition variable, for signaling a change of state. It is worth remembering that the IPC mechanisms used between separate processes — pipes, message queues, shared memory with semaphores — also work between threads in the same process, since threads are just schedulable units inside one process. Mutexes and condition variables are simply the lighter-weight tools built specifically for the single-process, shared-memory case.

Mutual Exclusion With pthread_mutex_t

The rule for using a mutex correctly is simple to state and easy to violate in practice: every shared resource gets one mutex, and every code path that reads or writes that resource must lock the mutex first and unlock it afterward, with no exceptions.

#include <pthread.h>

static pthread_mutex_t ep_lock = PTHREAD_MUTEX_INITIALIZER;
static long ep_shared_total = 0;

void ep_add_to_total(long value)
{
    pthread_mutex_lock(&ep_lock);
    ep_shared_total += value;
    pthread_mutex_unlock(&ep_lock);
}

Applying that one rule consistently solves most correctness problems, but mutexes have three well-known failure modes you should recognize by name even before you hit them in production.

Linux’s pthreads implementation supports priority-inheritance mutexes to address the second problem directly. You opt in by setting the protocol on a mutex attribute object before creating the mutex:

pthread_mutexattr_t ep_attr;
pthread_mutexattr_init(&ep_attr);
pthread_mutexattr_setprotocol(&ep_attr, PTHREAD_PRIO_INHERIT);

pthread_mutex_t ep_rt_lock;
pthread_mutex_init(&ep_rt_lock, &ep_attr);

Signaling State Changes With Condition Variables

A mutex alone only protects data — it does not tell a waiting thread when the data has become interesting. That is the job of a condition variable (pthread_cond_t). A condition is any boolean test on shared state — “is the queue empty,” “has the flag been set” — and the condition variable is the mechanism used to wake up threads that are waiting for that test to become true.

A condition variable is always paired with the mutex that protects the state being tested. The calling convention looks unusual the first time you see it: the waiting thread holds the mutex locked when it calls pthread_cond_wait(), and the function atomically unlocks the mutex while the thread sleeps, then re-locks it before returning — so there is no window where another thread could change the state between the check and the sleep.

Note the while loop around the wait call rather than a single if check. This guards against spurious wakeups, which POSIX explicitly permits, and against the case where two consumers both wake up but only one item was produced — re-checking the condition after waking is mandatory, not optional defensive style.

A Small Bounded Queue Example

Here is an original single-producer, single-consumer example built around a tiny fixed-size ring buffer, showing a mutex and condition variable working together.

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

#define EP_QUEUE_CAP 4

static int ep_queue[EP_QUEUE_CAP];
static int ep_head = 0, ep_tail = 0, ep_count = 0;

static pthread_mutex_t ep_qlock = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t  ep_qready = PTHREAD_COND_INITIALIZER;

void ep_queue_push(int value)
{
    pthread_mutex_lock(&ep_qlock);
    ep_queue[ep_tail] = value;
    ep_tail = (ep_tail + 1) % EP_QUEUE_CAP;
    ep_count++;
    pthread_cond_signal(&ep_qready);
    pthread_mutex_unlock(&ep_qlock);
}

int ep_queue_pop(void)
{
    pthread_mutex_lock(&ep_qlock);
    while (ep_count == 0)
        pthread_cond_wait(&ep_qready, &ep_qlock);

    int value = ep_queue[ep_head];
    ep_head = (ep_head + 1) % EP_QUEUE_CAP;
    ep_count--;
    pthread_mutex_unlock(&ep_qlock);
    return value;
}

void *ep_producer(void *arg)
{
    for (int i = 1; i <= 8; i++) {
        printf("producing %d\n", i);
        ep_queue_push(i);
    }
    return NULL;
}

void *ep_consumer(void *arg)
{
    for (int i = 0; i < 8; i++) {
        int v = ep_queue_pop();
        printf("consumed %d\n", v);
    }
    return NULL;
}

int main(void)
{
    pthread_t prod, cons;

    pthread_create(&cons, NULL, ep_consumer, NULL);
    pthread_create(&prod, NULL, ep_producer, NULL);

    pthread_join(prod, NULL);
    pthread_join(cons, NULL);
    return 0;
}

Build and run it:

$ gcc -Wall -pthread -o ep_sync_demo ep_sync_demo.c
$ ./ep_sync_demo
producing 1
producing 2
consumed 1
producing 3
consumed 2
producing 4
consumed 3
producing 5
consumed 4
producing 6
consumed 5
producing 7
consumed 6
producing 8
consumed 7
consumed 8

The exact interleaving of “producing” and “consumed” lines will vary between runs — that is expected, and is exactly why the mutex and condition variable are there: correctness does not depend on a particular ordering, only on the invariant that no item is read before it is written and none is lost.

Common Mistakes and Troubleshooting

Best Practices

• Keep the critical section — the code between lock and unlock — as short as possible.
• Never call blocking I/O while holding a mutex unless you fully understand the contention impact on every other thread waiting for that lock.
• Prefer pthread_cond_broadcast() over pthread_cond_signal() whenever more than one waiting thread might need to re-check the condition.
• Use PTHREAD_MUTEX_INITIALIZER for statically allocated mutexes and pthread_mutex_init() for dynamically allocated ones — don’t mix the two patterns on the same object.

Performance Considerations

A mutex itself is cheap in the uncontended case — locking and unlocking an uncontended futex-backed pthread mutex costs roughly the price of an atomic instruction. The real cost shows up under contention, when many threads queue up for the same lock and the kernel has to actually put threads to sleep and wake them. If profiling shows a single mutex as a bottleneck, the fix is almost always finer-grained locking — splitting one big lock into several smaller ones that protect independent pieces of data — rather than trying to make the lock itself faster.

Summary and Key Takeaways

• Always compile and link threaded programs with -pthread, not just -lpthread.
• Every shared resource needs exactly one mutex, locked on every access path with no exceptions.
• Watch for deadlock, priority inversion, and lock contention as the three classic mutex problems.
• Condition variables let a thread sleep until shared state changes, without busy-waiting.
• Always re-check the condition in a while loop after waking from pthread_cond_wait().

Conclusion

Mutexes and condition variables are the foundation everything else in POSIX threading is built on — thread pools, work queues, and higher-level concurrency libraries all reduce to these two primitives underneath. Get comfortable with the lock/unlock discipline and the wait-in-a-loop pattern shown here, and you will have the tools to reason about almost any threaded design you encounter in embedded Linux work. This lecture is one part of EmbeddedPathashala’s ongoing free Linux kernel development course — the next lecture in this chapter builds directly on these primitives to talk about how to structure processes and threads at a system-design level.

Frequently Asked Questions