Thread Safety: Concurrent Programming Fundamentals

Understanding Thread Safety

Thread safety is a fundamental concept in concurrent programming that ensures code functions correctly when accessed by multiple threads simultaneously. Without proper thread safety mechanisms, programs can exhibit unpredictable behavior, data corruption, and crashes.

In modern multi-core systems, thread safety is not optional—it's essential for building reliable, high-performance applications that can leverage parallel processing capabilities.

Interactive Thread Safety Demo

Experience how different synchronization mechanisms protect shared data from race conditions:

Speed:1000ms

Threads

Thread 00/5 ops

State: idle

Thread 10/5 ops

State: idle

Thread 20/5 ops

State: idle

Thread 30/5 ops

State: idle

Shared Memory

Counter: 0

Expected: 0

Current Value

Expected Value

Total Operations

Lost Updates

🏃 Race Condition Demo

Watch how threads read-modify-write the shared counter without synchronization. Notice how updates get lost when threads read stale values!

Why Thread Safety Matters

The Concurrency Challenge

When multiple threads access shared data without synchronization:

Race Conditions: Unpredictable results based on timing
Data Corruption: Partial writes visible to other threads
Lost Updates: Thread overwrites another's changes
Inconsistent State: Objects in invalid intermediate states

Real-World Consequences

Financial Systems: Incorrect account balances
Gaming: Physics glitches, inconsistent game state
Web Servers: Corrupted responses, security vulnerabilities
Databases: Lost transactions, corrupted indexes

Race Conditions Explained

What Is a Race Condition?

A race condition occurs when program behavior depends on the relative timing of events, especially thread execution order.

// Unsafe counter increment
int counter = 0;

void incrementCounter() {
    counter++;  // NOT atomic!
}

// Two threads calling incrementCounter() 1000 times each
// Expected: counter = 2000
// Actual: counter = 1000-2000 (unpredictable)

Why counter++ Isn't Atomic

The innocent-looking counter++ actually involves three operations:

Read: Load current value from memory
Modify: Add 1 to the value
Write: Store result back to memory

// counter++ in assembly (simplified)
mov  eax, [counter]  // Read
add  eax, 1          // Modify
mov  [counter], eax  // Write

If two threads interleave these operations, updates can be lost!

Synchronization Primitives

1. Mutexes (Mutual Exclusion)

Mutexes ensure only one thread can access a critical section at a time.

std::mutex mtx;
int shared_data = 0;

void safeIncrement() {
    std::lock_guard<std::mutex> lock(mtx);
    shared_data++;  // Protected by mutex
}  // lock automatically released

Pros:

Complete protection for critical sections
Works for complex operations
RAII with lock_guard ensures proper unlocking

Cons:

Performance overhead
Can cause contention
Risk of deadlock

2. Atomic Operations

Atomic operations complete as a single, indivisible unit.

std::atomic<int> counter{0};

void atomicIncrement() {
    counter.fetch_add(1);  // Atomic operation
    // Or simply: counter++;
}

Pros:

Lock-free
Better performance for simple operations
No deadlock risk

Cons:

Limited to simple operations
Memory ordering complexity
Not suitable for complex critical sections

3. Read-Write Locks

Allow multiple readers or one writer.

std::shared_mutex rw_mutex;
std::vector<int> data;

void readData() {
    std::shared_lock lock(rw_mutex);
    // Multiple threads can read simultaneously
    auto value = data[0];
}

void writeData(int value) {
    std::unique_lock lock(rw_mutex);
    // Exclusive access for writing
    data.push_back(value);
}

Memory Ordering and Visibility

The Memory Model Challenge

Modern CPUs and compilers reorder operations for performance:

// Thread 1
data = 42;
flag = true;

// Thread 2
if (flag) {
    use(data);  // data might not be 42!
}

Memory Ordering Solutions

std::atomic<bool> flag{false};
int data = 0;

// Thread 1 - Release
data = 42;
flag.store(true, std::memory_order_release);

// Thread 2 - Acquire
if (flag.load(std::memory_order_acquire)) {
    use(data);  // Guaranteed to see data = 42
}

Common Thread Safety Patterns

1. Double-Checked Locking

class Singleton {
    static std::atomic<Singleton*> instance;
    static std::mutex mtx;

public:
    static Singleton* getInstance() {
        Singleton* tmp = instance.load(std::memory_order_acquire);
        if (tmp == nullptr) {
            std::lock_guard<std::mutex> lock(mtx);
            tmp = instance.load(std::memory_order_relaxed);
            if (tmp == nullptr) {
                tmp = new Singleton;
                instance.store(tmp, std::memory_order_release);
            }
        }
        return tmp;
    }
};

2. Producer-Consumer Queue

template<typename T>
class ThreadSafeQueue {
    std::queue<T> queue;
    mutable std::mutex mtx;
    std::condition_variable cv;

public:
    void push(T value) {
        {
            std::lock_guard<std::mutex> lock(mtx);
            queue.push(std::move(value));
        }
        cv.notify_one();
    }

    T pop() {
        std::unique_lock<std::mutex> lock(mtx);
        cv.wait(lock, [this]{ return !queue.empty(); });
        T value = std::move(queue.front());
        queue.pop();
        return value;
    }
};

3. Copy-on-Write

class COWData {
    struct Data {
        std::vector<int> values;
        // ... other data
    };
    
    std::shared_ptr<const Data> data;
    mutable std::shared_mutex mtx;

public:
    void modify() {
        std::unique_lock lock(mtx);
        // Create copy if shared
        if (!data.unique()) {
            data = std::make_shared<Data>(*data);
        }
        // Now safe to modify
        const_cast<Data*>(data.get())->values.push_back(42);
    }

    std::vector<int> read() const {
        std::shared_lock lock(mtx);
        return data->values;
    }
};

Deadlock Prevention

The Four Conditions for Deadlock

Mutual Exclusion: Resources cannot be shared
Hold and Wait: Thread holds resources while waiting
No Preemption: Resources cannot be forcibly taken
Circular Wait: Circular chain of dependencies

Prevention Strategies

1. Lock Ordering

// Always acquire locks in the same order
void transfer(Account& from, Account& to, int amount) {
    // Order by account ID to prevent deadlock
    if (from.id < to.id) {
        std::lock_guard lock1(from.mutex);
        std::lock_guard lock2(to.mutex);
        // Transfer logic
    } else {
        std::lock_guard lock1(to.mutex);
        std::lock_guard lock2(from.mutex);
        // Transfer logic
    }
}

2. Try-Lock with Timeout

bool tryTransfer(Account& from, Account& to, int amount) {
    using namespace std::chrono;
    
    if (from.mutex.try_lock_for(milliseconds(100))) {
        std::lock_guard lock1(from.mutex, std::adopt_lock);
        
        if (to.mutex.try_lock_for(milliseconds(100))) {
            std::lock_guard lock2(to.mutex, std::adopt_lock);
            // Transfer logic
            return true;
        }
    }
    return false;  // Retry later
}

3. std::lock for Multiple Mutexes

void safeTransfer(Account& from, Account& to, int amount) {
    std::lock(from.mutex, to.mutex);  // Deadlock-free
    std::lock_guard lock1(from.mutex, std::adopt_lock);
    std::lock_guard lock2(to.mutex, std::adopt_lock);
    // Transfer logic
}

Performance Considerations

Lock Granularity

Coarse-Grained Locking

class BankSystem {
    std::mutex global_mutex;  // One lock for everything
    std::map<int, Account> accounts;

    void transfer(int from_id, int to_id, int amount) {
        std::lock_guard lock(global_mutex);
        // Simple but limits parallelism
    }
};

Fine-Grained Locking

class BankSystem {
    struct Account {
        int balance;
        mutable std::mutex mutex;  // Per-account lock
    };
    std::map<int, Account> accounts;

    void transfer(int from_id, int to_id, int amount) {
        // Lock only affected accounts
        // Better parallelism
    }
};

Lock-Free Data Structures

template<typename T>
class LockFreeStack {
    struct Node {
        T data;
        std::atomic<Node*> next;
        Node(T val) : data(std::move(val)), next(nullptr) {}
    };

    std::atomic<Node*> head{nullptr};

public:
    void push(T value) {
        Node* new_node = new Node(std::move(value));
        new_node->next = head.load();
        while (!head.compare_exchange_weak(new_node->next, new_node))
            ; // Retry on failure
    }

    std::optional<T> pop() {
        Node* old_head = head.load();
        while (old_head && 
               !head.compare_exchange_weak(old_head, old_head->next))
            ; // Retry
        
        if (old_head) {
            T value = std::move(old_head->data);
            delete old_head;
            return value;
        }
        return std::nullopt;
    }
};

Testing Thread Safety

1. Thread Sanitizer

# Compile with ThreadSanitizer
g++ -fsanitize=thread -g program.cpp

# Run to detect races
./a.out

2. Stress Testing

void stressTest() {
    const int num_threads = 100;
    const int operations_per_thread = 10000;
    ThreadSafeCounter counter;
    
    std::vector<std::thread> threads;
    for (int i = 0; i < num_threads; ++i) {
        threads.emplace_back([&]() {
            for (int j = 0; j < operations_per_thread; ++j) {
                counter.increment();
            }
        });
    }
    
    for (auto& t : threads) {
        t.join();
    }
    
    assert(counter.get() == num_threads * operations_per_thread);
}

Best Practices

Minimize Shared State: Less sharing = fewer synchronization needs
Immutable Data: Can't have races on data that doesn't change
Message Passing: Consider actor model or channels
RAII for Locks: Use lock_guard, unique_lock
Document Thread Safety: Be explicit about guarantees
Prefer std::atomic: For simple shared data
Avoid Nested Locks: Reduce deadlock risk
Test Thoroughly: Use tools and stress tests

Common Pitfalls

struct alignas(64) CacheLinePadded {
    std::atomic<int> value;
    char padding[64 - sizeof(std::atomic<int>)];
};

2. ABA Problem

// Thread 1: Read A, prepare to CAS
// Thread 2: Change A→B→A
// Thread 1: CAS succeeds but state changed!

3. Priority Inversion

// Low priority thread holds lock
// High priority thread waits
// Medium priority threads run instead!

Modern C++ Thread Safety Features

std::synchronized_value (C++20)

std::synchronized_value<std::vector<int>> sync_vec;

sync_vec->push_back(42);  // Automatically locked

std::jthread (C++20)

{
    std::jthread worker([](std::stop_token st) {
        while (!st.stop_requested()) {
            // Do work
        }
    });
}  // Automatically joins and stops

std::latch and std::barrier (C++20)

std::latch start_signal{1};
std::vector<std::thread> threads;

for (int i = 0; i < 10; ++i) {
    threads.emplace_back([&]() {
        start_signal.wait();  // Wait for signal
        // Race!
    });
}

start_signal.count_down();  // Start all threads

Thread safety connects to many other important topics:

Smart Pointers: Thread-safe reference counting
Memory RAII: Automatic lock management
Modern C++ Features: Threading utilities
NUMA Architecture: Thread affinity and memory
Memory Access Patterns: Cache effects in concurrent code

Conclusion

Thread safety is essential for correct concurrent programs. While it adds complexity, modern C++ provides powerful tools to write safe, efficient multithreaded code. Start with simple synchronization primitives, understand the memory model, and gradually adopt lock-free techniques where performance demands it. Remember: correctness first, optimization second!

Table of Contents

Threads

Shared Memory

🏃 Race Condition Demo