Mutex Locks for Thread Synchronization

The Problem: Race Conditions and Critical Sections

You've encountered the concept of race conditions before. They occur when multiple threads access and manipulate a shared piece of data concurrently, and the final outcome depends on the unpredictable timing of their execution.

Let's watch a brief video that provides an excellent demonstration of this problem using a bank account analogy, which is a classic example in concurrency.

The fundamental issue is that an operation like balance = balance + amount is not a single, indivisible (or atomic) instruction. At the machine level, it involves three distinct steps:

1. Read: Load the value of balance from memory into a CPU register.
2. Modify: Add amount to the value in the register.
3. Write: Store the new value from the register back into memory.

A race condition occurs when the scheduler pauses one thread after it has read the value, and another thread then runs through all three steps. When the first thread resumes, it's working with an outdated, or stale, value.

The section of your code that accesses the shared resource (like the balance variable) is called a critical section. To prevent race conditions, we must guarantee mutual exclusion, meaning only one thread can be executing within that critical section at any given time.

The Solution: pthread_mutex_lock and pthread_mutex_unlock

The Pthreads library provides a simple and powerful mechanism to enforce mutual exclusion: the mutex. Think of a mutex as a key to a room (the critical section). A thread must acquire the key before entering the room. If another thread arrives and the key is gone, it must wait outside until the first thread leaves and returns the key.

The functions for this are pthread_mutex_lock() and pthread_mutex_unlock().

• int pthread_mutex_lock(pthread_mutex_t *mutex);
  • Attempts to acquire the lock.
  • If the mutex is currently unlocked, the calling thread acquires it immediately and continues execution.
  • If the mutex is already locked by another thread, the calling thread blocks (it pauses execution and waits) until the mutex is unlocked.
• int pthread_mutex_unlock(pthread_mutex_t *mutex);
  • Releases a lock that the calling thread currently holds.
  • If other threads are blocked waiting for this mutex, one of them will be woken up and will acquire the lock.

Let's see this in action. The following video takes a simple counter example, which has a race condition, and fixes it using these two functions.

The core logic is as simple as it looks:

// Before entering the critical section
pthread_mutex_lock(&my_mutex);

// --- Critical Section Start ---
// Only one thread can be here at a time.
shared_variable++;
// --- Critical Section End ---

// After leaving the critical section
pthread_mutex_unlock(&my_mutex);

The following diagram illustrates this sequence. Imagine G1 and G2 are two threads trying to access a shared resource n.

Practical Implementation and Performance

Let's combine what you've learned about robust initialization (last lesson) and locking (this lesson) into a complete, correct program. We'll use the textual resource from the University of Illinois, which provides excellent examples and analysis.

The Cost of Locking

As the reading points out, locking and unlocking a mutex is not free. It involves system calls and memory synchronization that are much more expensive than a simple variable increment.

The second example in the reading, where the lock is inside the loop, is correct but inefficient:

for(i = 0; i < 10000000; i++) {
    pthread_mutex_lock(&m);
    sum += 1;
    pthread_mutex_unlock(&m);
}

This code forces the threads to serialize their work entirely. You've effectively lost any benefit of parallelism because the threads spend most of their time waiting for the lock.

The "Minimize Lock Hold Time" Pattern

The third example demonstrates a crucial optimization pattern: do as much work as possible outside the critical section.

int local_sum = 0;
for(i = 0; i < 10000000; i++) {
    local_sum += 1; // No lock needed, 'local_sum' is private to the thread
}

pthread_mutex_lock(&m);
global_sum += local_sum; // Lock held for just one operation
pthread_mutex_unlock(&m);

Here, each thread computes its sub-total using its own private local_sum variable. Since this variable isn't shared, no lock is needed. Only at the very end does the thread acquire the lock for the single, brief operation of adding its local result to the shared global_sum. This minimizes lock contention and maximizes parallel execution. This principle is fundamental to writing high-performance concurrent code.

Rules of Engagement for Mutexes

When using mutexes, a few strict rules apply. Breaking them can lead to bugs that are difficult to diagnose, including deadlocks (which we'll cover in a future module).

1. A mutex protects a section of code, not data. A mutex is a signaling mechanism. It's up to you, the programmer, to ensure that every critical section that accesses a piece of shared data is protected by the same mutex.
2. The thread that locks a mutex must be the one to unlock it. The concept of ownership is built into standard Pthreads mutexes.
3. Always unlock a mutex. Be careful in functions with multiple return paths. If you lock a mutex at the start of a function and then return early due to an error, you must ensure you unlock the mutex before returning. Failure to do so will cause any other thread waiting on that mutex to block forever.
4. Keep critical sections as small and fast as possible. As we saw with the performance example, holding a lock for a long time creates a bottleneck. Move any work that doesn't strictly need the shared data outside the lock/unlock block.

long accounts[2] = {1000, 1000};
pthread_mutex_t m_deposits = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t m_withdrawals = PTHREAD_MUTEX_INITIALIZER;

// Function run by one thread
void* deposit_thread(void* arg) {
    for (int i = 0; i < 10000; ++i) {
        pthread_mutex_lock(&m_deposits);
        accounts[0] += 10;
        accounts[1] += 10;
        pthread_mutex_unlock(&m_deposits);
    }
    return NULL;
}

// Function run by another thread
void* withdrawal_thread(void* arg) {
    for (int i = 0; i < 10000; ++i) {
        pthread_mutex_lock(&m_withdrawals);
        accounts[0] -= 10;
        accounts[1] -= 10;
        pthread_mutex_unlock(&m_withdrawals);
    }
    return NULL;
}

pthread_mutex_t m_accounts = PTHREAD_MUTEX_INITIALIZER;

// ...

// In deposit_thread:
pthread_mutex_lock(&m_accounts);
// ...
pthread_mutex_unlock(&m_accounts);

// In withdrawal_thread:
pthread_mutex_lock(&m_accounts);
// ...
pthread_mutex_unlock(&m_accounts);

Conclusion

You have now learned the most fundamental synchronization pattern in threaded programming. By wrapping critical sections with pthread_mutex_lock and pthread_mutex_unlock, you can prevent race conditions and ensure the integrity of shared data.

Key Takeaways:

• A critical section is a piece of code that accesses a shared resource.
• Mutual exclusion, which prevents multiple threads from executing in a critical section simultaneously, is necessary for correctness.
• The pthread_mutex_lock() and pthread_mutex_unlock() functions are the standard tools for enforcing mutual exclusion.
• If a thread calls pthread_mutex_lock() on a mutex held by another thread, it will block until the mutex is released.
• For performance, always aim to minimize lock hold time by keeping critical sections as short as possible.

Preview of the Next Lesson:
The pthread_mutex_lock function is a blocking call. The thread simply stops and waits. But what if you don't want to wait? What if you want to test if a lock is available and, if it isn't, go do some other useful work instead of blocking? In the next lesson, we will explore this scenario by learning to use pthread_mutex_trylock for non-blocking lock acquisition strategies.