Thread-Safe Counter with Mutex

The Problem: Race Conditions

Let's start by understanding the problem we're trying to solve. Imagine you have a simple global counter that you want multiple threads to increment. Each thread will increment the counter a million times. If you have two threads, you'd expect the final value to be two million. Let's see what actually happens.

The following video does an excellent job of demonstrating this exact scenario.

The unpredictable result you just saw is caused by a race condition. This occurs because the increment operation, mails++, is not a single, indivisible (or atomic) operation. At the machine level, it's a sequence of distinct steps:

1. Read: Load the current value of the counter from memory into a CPU register.
2. Modify: Increment the value in the CPU register.
3. Write: Store the new value from the CPU register back into memory.

The operating system can pause a thread and switch to another at any point. Imagine two threads running this sequence.

Both threads performed an increment, but the final value only increased by one. An update was lost. This is a classic data race.

The Solution: Mutual Exclusion with a Mutex

To prevent this, we must ensure that the read-modify-write sequence is executed by only one thread at a time. The block of code that accesses the shared resource (in this case, the increment operation) is called a critical section. We need to guarantee mutual exclusion—if one thread is in the critical section, no other thread can enter it.

This is precisely what a mutex (mutual exclusion lock) is for.

A mutex acts as a gatekeeper for the critical section. Before entering, a thread must acquire the lock. After it's done, it must release the lock.

Implementing a Thread-Safe Counter

Now, let's put this into practice and fix our counter. This involves four key pthread functions:

• pthread_mutex_init(): To initialize the mutex before any thread can use it.
• pthread_mutex_lock(): To acquire the lock before the critical section.
• pthread_mutex_unlock(): To release the lock after the critical section.
• pthread_mutex_destroy(): To clean up the mutex when it's no longer needed.

The video you watched earlier continues to show exactly how to implement this solution.

Here is a complete, robust implementation that incorporates the principles from the video as well as the error checking we covered in a previous lesson.

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

// Shared global variable
long long counter = 0;

// Mutex to protect the shared counter
pthread_mutex_t counter_mutex;

// Thread function to increment the counter
void* thread_routine(void* arg) {
    int iterations = *(int*)arg;
    for (int i = 0; i < iterations; i++) {
        // --- Start of Critical Section ---
        if (pthread_mutex_lock(&counter_mutex) != 0) {
            perror("Failed to lock mutex");
            return NULL;
        }

        counter++;

        if (pthread_mutex_unlock(&counter_mutex) != 0) {
            perror("Failed to unlock mutex");
            return NULL;
        }
        // --- End of Critical Section ---
    }
    return NULL;
}

int main(int argc, char* argv[]) {
    int num_threads = 10;
    int iterations_per_thread = 1000000;

    pthread_t threads[num_threads];

    // Initialize the mutex
    if (pthread_mutex_init(&counter_mutex, NULL) != 0) {
        perror("Failed to initialize mutex");
        return 1;
    }

    // Create threads
    for (int i = 0; i < num_threads; i++) {
        if (pthread_create(&threads[i], NULL, &thread_routine, &iterations_per_thread) != 0) {
            perror("Failed to create thread");
            return 1;
        }
    }

    // Wait for all threads to finish
    for (int i = 0; i < num_threads; i++) {
        if (pthread_join(threads[i], NULL) != 0) {
            perror("Failed to join thread");
            return 1;
        }
    }

    // Destroy the mutex
    pthread_mutex_destroy(&counter_mutex);

    printf("Expected counter value: %d\n", num_threads * iterations_per_thread);
    printf("Actual counter value:   %lld\n", counter);

    return 0;
}

Compile and run this code. You will see that the actual counter value now consistently matches the expected value, no matter how many times you run it.

gcc -o safe_counter safe_counter.c -lpthread
./safe_counter

Conclusion

Today you've tackled one of the most fundamental challenges in concurrent programming. By understanding the non-atomic nature of simple operations and applying a mutex, you can now write code that correctly and safely handles shared data.

Key Takeaways:

• Race Conditions: Occur when multiple threads access shared data concurrently, and the final outcome depends on the unpredictable timing of their execution. This is often caused by non-atomic read-modify-write operations.
• Critical Section: A piece of code that accesses a shared resource and must not be executed by more than one thread at a time.
• Mutex for Thread Safety: The pthread_mutex_lock and pthread_mutex_unlock functions are used to create a critical section, ensuring mutual exclusion and preventing race conditions, leading to correct and predictable program behavior.

Preview of the Next Lesson:
We've successfully used a mutex to make threads wait their turn to access data. However, sometimes threads need to wait for a specific condition to become true—for example, a "consumer" thread might need to wait for a "producer" thread to add an item to an empty queue. A mutex alone is not sufficient for this kind of signaling. In our next lesson, we will begin Module 2 by introducing a new synchronization tool as we learn to initialize and destroy condition variables alongside their associated mutexes.