Protecting Shared Data with Mutex and Lock Guard

The Concept of Mutual Exclusion

The fundamental idea behind protecting shared data is mutual exclusion. We need a mechanism to ensure that if one thread is modifying a shared resource, all other threads must wait until it's finished. The C++ standard library provides this mechanism through the std::mutex class.

Think of a std::mutex as a key to a room that can only hold one person. A thread wanting to enter the "room" (the critical section of code) must first acquire the key (lock the mutex). If another thread already has the key, it must wait. Once the first thread is done, it releases the key (unlocks the mutex), allowing a waiting thread to take its turn.

A First Attempt: Manual Locking

Let's fix the data race from our previous examples. The most direct way to use a std::mutex is by calling its lock() and unlock() member functions around the code that accesses the shared data.

The following video demonstrates exactly this, using a shared std::cout resource as the subject of the data race.

By wrapping the access to the shared resource between mu.lock() and mu.unlock(), we create a critical section and guarantee that only one thread can execute that code at a time. The data race is eliminated.

The Pitfall of Manual Locking and the Power of RAII

While lock() and unlock() work, they are fragile and considered bad practice in modern C++. Consider this scenario:

std::mutex my_mutex;
SharedData my_data;

void process_data() {
    my_mutex.lock();
    // What if this line throws an exception?
    my_data.do_something_that_might_fail(); 
    my_mutex.unlock(); // This line will never be reached!
}

If an exception occurs within the critical section, the unlock() call is skipped. The mutex remains locked forever, and any other thread waiting for it will be blocked indefinitely. This is a form of deadlock.

The C++ solution to this is a powerful and idiomatic pattern called RAII (Resource Acquisition Is Initialization). The principle is to tie the lifetime of a resource (like a mutex lock) to the lifetime of an object. The resource is acquired in the object's constructor and released in its destructor. Since destructors are guaranteed to be called when an object goes out of scope—whether by normal execution or by an exception causing the stack to "unwind"—the resource is always released correctly.

std::lock_guard: RAII in Action

The C++ library provides the perfect RAII wrapper for this job: std::lock_guard. When you create a std::lock_guard object, its constructor locks the provided mutex. When the lock_guard goes out of scope, its destructor automatically unlocks the mutex.

Our previous example becomes:

#include <mutex> // Required header

void safe_process_data() {
    // The lock_guard acquires the lock on my_mutex upon construction.
    std::lock_guard<std::mutex> guard(my_mutex); 
    
    my_data.do_something_that_might_fail();

} // `guard` goes out of scope here. Its destructor is called,
  // which unlocks my_mutex, even if an exception was thrown.

This code is clean, simple, and exception-safe. You should always prefer std::lock_guard over manual lock() and unlock() calls.

Let's see this in action.

To reinforce this critical concept, let's see it applied to the producer-consumer problem, which is highly relevant to the telemetry engine we're building.

Best Practices for Structuring Thread-Safe Code

Now that you have the right tool, it's crucial to use it correctly. Effective lock-based concurrency is about careful software design, not just syntax.

1. Encapsulate Your Data and Mutex

A mutex and the data it protects should live together. The best way to enforce this is to make them both private members of a class. This prevents other parts of the code from accessing the data without going through the public member functions, which are responsible for locking the mutex.

2. Don't Leak Handles to Protected Data

This is a critical rule for systems programming. Once you have locked your data inside a class, never return a raw pointer or reference to it from a member function. Doing so creates a backdoor that allows any other thread to access and modify the data directly, completely bypassing the mutex's protection.

The following segment of the Bo Qian video masterfully illustrates both of these points.

Let's look at another code example that drives this point home.

3. Design Thread-Safe Interfaces

Even with proper locking inside each member function, you can still have race conditions if your class interface is not designed for concurrency. This is an interface-level bug, not an implementation-level one.

The classic example is a thread-safe stack with separate top() and pop() methods.

1. Thread A calls top() and gets the value X. The lock is released.
2. The OS pauses Thread A.
3. Thread B calls top() and also gets the value X. The lock is released.
4. Thread A resumes and calls pop(), removing X.
5. Thread B resumes and calls pop(), removing the next element, Y.

The result: value X was processed twice, and value Y was lost. The solution is to combine top() and pop() into a single atomic operation.

#include <iostream>
#include <vector>
#include <string>
#include <thread>

class Logger {
private:
    std::vector<std::string> messages;

public:
    void add_message(const std::string& msg) {
        messages.push_back(msg);
    }

    void print_last_message() {
        if (!messages.empty()) {
            std::cout << messages.back() << std::endl;
        }
    }
};

void writer_thread(Logger& logger, int id) {
    for (int i = 0; i < 10; ++i) {
        std::string msg = "Message from writer " + std::to_string(id) + ", number " + std::to_string(i);
        logger.add_message(msg);
    }
}

// In main():
// Logger shared_logger;
// std::thread t1(writer_thread, std::ref(shared_logger), 1);
// std::thread t2(writer_thread, std::ref(shared_logger), 2);
// t1.join();
// t2.join();

Conclusion

Today you've acquired the fundamental tools for writing correct lock-based concurrent programs. You have learned how to eliminate data races and how to start thinking about thread-safe design.

Key Takeaways:

• std::mutex provides a mechanism for mutual exclusion, allowing only one thread at a time into a critical section.
• Manual lock() and unlock() calls are dangerous. Always prefer the RAII pattern with std::lock_guard, which guarantees the mutex is unlocked, even in the presence of exceptions.
• Good concurrent design involves encapsulating the shared data and its mutex within a class.
• Never leak pointers or references to protected data, as this breaks the encapsulation and bypasses the lock.
• Simply locking individual methods is not enough; you must design your class interfaces to be atomic and prevent high-level race conditions.

You now have a solid foundation for protecting shared state. However, mutexes come with their own costs. What happens when a consumer thread needs to wait for data from a producer? It could repeatedly lock the mutex, check if the queue is empty, and unlock if it is. This "busy-waiting" wastes CPU cycles.

In our next lesson, we will introduce std::condition_variable, a more advanced primitive that allows threads to wait efficiently for a specific condition to become true without burning CPU time. This will be the next key component in our telemetry engine's data pipeline.