Mutex Concept: The Foundation of Mutual Exclusion - Mutex Locks: Mutual Exclusion Primitives | OneNoughtOne

0/236

Operating SystemsMutex Locks

Mutex Locks: Mutual Exclusion Primitives

LevelIntermediate

Duration60 mins

TopicMutex Locks

1 / 5

Mutex Concept: The Foundation of Mutual Exclusion

The Lock That Guards Everything

In the world of concurrent programming, shared mutable state is the root of all evil. When multiple threads or processes access the same memory region simultaneously—and at least one of them is writing—chaos ensues. Data structures become corrupted. Invariants are violated. Programs produce different results on every run. This is the fundamental problem of concurrency.

The mutex (short for mutual exclusion) is the answer to this problem. It is arguably the most important synchronization primitive in all of computer science—a simple concept that enables all of modern concurrent software to function correctly.

What You Will Learn

By the end of this page, you will understand what a mutex is at its deepest level—not just as an API call, but as a precisely defined mathematical object with clear semantics. You will understand why mutexes exist, what guarantees they provide, what happens when they are misused, and how they relate to the critical section problem from synchronization theory.

The Critical Section Problem Revisited

Before we can understand mutexes, we must understand the problem they solve. The critical section problem is one of the oldest and most fundamental problems in concurrent computing.

Definition: A critical section is a segment of code that accesses shared resources (variables, data structures, files, devices) that must not be accessed by more than one thread or process simultaneously.

The critical section problem asks: How do we ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical section?

This seemingly simple question has occupied computer scientists for over six decades, and its correct solution is essential for every concurrent program ever written.

Why This Matters

Without a solution to the critical section problem, concurrent programs cannot safely share data. Every bank transaction, every database update, every file write, every game state change—all would be subject to race conditions that corrupt data and crash systems.

The Three Requirements for Any Solution:

Any valid solution to the critical section problem must satisfy three fundamental properties:

1. Mutual Exclusion If process P is executing in its critical section, then no other processes can be executing in their critical sections. Only one process at a time may occupy the critical region.

2. Progress If no process is executing in its critical section and some processes wish to enter their critical sections, then the selection of which process will enter next cannot be postponed indefinitely. The system must make forward progress.

3. Bounded Waiting There exists a bound (limit) on the number of times other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted. No process should wait forever.

critical_section_structure.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// The general structure of a process with a critical section
// This structure applies to ALL concurrent programs
 
while (true) {
    // ENTRY SECTION
    // Code that requests permission to enter critical section
    // Must ensure mutual exclusion is maintained
    acquire_lock();
    
    // CRITICAL SECTION
    // Code that accesses shared resources
    // Only ONE thread/process can be here at a time
    shared_counter++;
    update_shared_data_structure();
    
    // EXIT SECTION  
    // Code that releases the critical section
    // Must signal that other processes may now enter
    release_lock();
    
    // REMAINDER SECTION
    // Code that does not access shared resources
    // Multiple threads can execute here simultaneously
    do_local_work();
}

The Mutex as the Solution:

A mutex is a synchronization primitive specifically designed to solve the critical section problem. It provides:

Mutual exclusion through its locking mechanism—only one thread can hold the lock
Progress by ensuring a thread waiting for the lock will eventually acquire it
Bounded waiting through fair scheduling policies in modern implementations

The mutex is not just a solution to the critical section problem—it is the canonical solution used in virtually all systems programming today.

What Exactly Is a Mutex?

A mutex is a synchronization object that can be in one of two states: locked (or held) or unlocked (or free). It provides two fundamental operations:

Lock (also called acquire, enter, or P): Attempt to take ownership of the mutex
Unlock (also called release, leave, or V): Relinquish ownership of the mutex

The Fundamental Semantic Contract:

The mutex provides a deceptively simple guarantee: between any lock and its corresponding unlock, no other thread can successfully lock the same mutex. This single guarantee is what makes mutexes so powerful—and also what makes them so easy to misuse.

Mutex Semantic Properties

•Ownership Semantics — A mutex is owned by the thread that acquired it. Only the owning thread can release it. Attempting to release a mutex you don't own results in undefined behavior.
•Binary State — Unlike counting semaphores, a mutex has exactly two states. You cannot 'lock twice' or 'unlock twice' (though recursive mutexes modify this—covered later).
•Blocking Behavior — When a thread attempts to lock an already-locked mutex, it blocks (waits) until the mutex becomes available. The thread cannot proceed until it acquires the lock.
•Atomicity of Operations — Both lock and unlock operations are atomic—they cannot be interrupted partway through. This is essential for correctness.
•Memory Ordering Guarantees — Lock and unlock operations serve as memory barriers, ensuring proper visibility of changes between threads (implementation-dependent).

mutex_mental_model.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// Mental model: A mutex is like a bathroom lock
//
// Bathroom analogy:
// - Only one person can use the bathroom at a time
// - You lock the door when you enter
// - You unlock the door when you leave
// - Others must wait outside if it's occupied
 
// In code, this translates to:
typedef struct {
    int locked;          // 0 = unlocked, 1 = locked
    thread_t owner;      // Which thread holds the lock
    queue_t waiters;     // Threads waiting for this lock
} mutex_t;
 
// Abstract operations (implementation details vary):
void mutex_lock(mutex_t *m) {
    // IF mutex is unlocked:
    //   - Mark it locked
    //   - Record us as the owner
    //   - Return immediately (we acquired the lock)
    // ELSE (mutex is locked):
    //   - Add ourselves to the wait queue
    //   - Block (go to sleep) until woken up
    //   - When woken: we now own the lock
}
 
void mutex_unlock(mutex_t *m) {
    // ASSERT: We are the owner (undefined behavior otherwise)
    // IF waiters are queued:
    //   - Remove one waiter from queue
    //   - Transfer ownership to that waiter
    //   - Wake up that waiter
    // ELSE:
    //   - Mark mutex as unlocked
    //   - Clear ownership
}

The Bathroom Analogy

Think of a mutex like a single-occupancy bathroom with a lock. When you enter, you lock the door. Anyone else who tries to enter must wait outside. When you leave, you unlock the door, and the next person in line can enter. This is exactly how a mutex works—simple, intuitive, and effective.

Mutex vs. Other Synchronization Primitives

The world of synchronization is rich with various primitives, each designed for specific use cases. Understanding where mutexes fit—and how they differ from alternatives—is essential for choosing the right tool.

Mutex vs. Semaphore:

Semaphores (invented by Dijkstra) are more general counting mechanisms. A semaphore maintains a count and allows up to N concurrent accesses (where N is the semaphore's initial value). A binary semaphore (count = 1) is functionally similar to a mutex but lacks ownership semantics.

Key Difference: A mutex has an owner—only the thread that locked it can unlock it. A semaphore can be signaled (V operation) by any thread, not just the one that waited (P operation). This makes mutexes safer for protecting critical sections, while semaphores are better for signaling and resource counting.

Comparison of Synchronization Primitives
Primitive	Purpose	Ownership	Count	Blocking	Typical Use Case
Mutex	Mutual exclusion	Yes—only owner can unlock	Binary (0/1)	Yes—waits if locked	Protecting critical sections
Binary Semaphore	Signaling or mutex-like	No—any thread can signal	Binary (0/1)	Yes—waits if count is 0	Inter-thread signaling
Counting Semaphore	Resource limiting	No—any thread can signal	N (arbitrary)	Yes—waits if count is 0	Resource pool management
Spinlock	Short critical sections	Yes—owner releases	Binary (0/1)	No—spins in busy-wait	Kernel code, short locks
RWLock	Readers/writers pattern	Yes—owner releases	Multiple readers, one writer	Yes—semantics vary	Read-heavy workloads
Condition Variable	Event notification	N/A—used with mutex	N/A	Yes—waits for condition	Producer-consumer patterns

Mutex vs. Spinlock:

Both mutexes and spinlocks provide mutual exclusion, but their waiting behavior differs fundamentally:

Mutex (Blocking Lock): When a thread cannot acquire a mutex, it blocks—the operating system removes it from the CPU and puts it to sleep. The thread consumes no CPU time while waiting. When the mutex is released, the OS wakes a waiting thread.
Spinlock: When a thread cannot acquire a spinlock, it spins—the thread stays on the CPU in a tight loop, continuously checking if the lock is available. The thread consumes 100% CPU while waiting.

When to use each:

Use mutexes when the critical section may take a long time, or when threads are competing heavily
Use spinlocks when the critical section is extremely short (a few instructions), and blocking overhead would exceed spin time

The Cost of Context Switches

Blocking on a mutex involves a context switch—saving the current thread's state, selecting another thread, and restoring that thread's state. This typically costs 1,000–10,000 CPU cycles. If your critical section is shorter than this, spinning might be more efficient despite 'wasting' CPU cycles.

Mutex vs. Condition Variable:

A condition variable is not a replacement for a mutex—it is a complement to a mutex. Condition variables allow threads to wait for a specific condition to become true, but they must always be used in conjunction with a mutex that protects the shared state being tested.

Mutex alone: 'Only one thread can access this data at a time'
Mutex + Condition Variable: 'Only one thread can access this data, AND threads can wait until specific conditions are met'

Condition variables enable patterns like producer-consumer, where a consumer thread waits until data is available, rather than polling a queue repeatedly.

The Formal Definition of Mutex Behavior

For those who appreciate mathematical precision, we can define mutex behavior formally. This rigor is not academic pedantry—it is essential for verifying concurrent programs and understanding subtle bugs.

State Space: A mutex M at any instant is characterized by:

A state s ∈ {UNLOCKED, LOCKED}
An owner thread t ∈ {⊥, T₁, T₂, ..., Tₙ} where ⊥ means 'no owner'
A set of waiting threads W ⊆ {T₁, T₂, ..., Tₙ}

Invariants (always true):

If s = UNLOCKED, then owner = ⊥
If s = LOCKED, then owner ∈ {T₁, T₂, ..., Tₙ} (exactly one thread)
owner ∉ W (the owner is never in the wait set)

mutex_formal_semantics.txt

Formal

OPERATION: lock(M, T)
─────────────────────────────────────────────────────
Preconditions:
  - Thread T is not already the owner of M
  - Thread T is not in the wait set W of M
 
Atomic Behavior:
  IF M.state = UNLOCKED:
    M.state := LOCKED
    M.owner := T
    // Immediate return: lock acquired
  ELSE:  // M.state = LOCKED
    M.waiters := M.waiters ∪ {T}
    block(T)  // Suspend T until awakened
    // When T is awakened:
    ASSERT: M.owner = T  // Ownership transferred before wakeup
    // Return: lock acquired
 
Postconditions:
  - M.state = LOCKED
  - M.owner = T
  - T ∉ M.waiters
 
 
OPERATION: unlock(M, T)
─────────────────────────────────────────────────────
Preconditions:
  - M.state = LOCKED
  - M.owner = T  // Only owner can unlock
 
Atomic Behavior:
  IF M.waiters = ∅:
    M.state := UNLOCKED
    M.owner := ⊥
  ELSE:
    // Choose a waiter (scheduling policy determines selection)
    T' := select(M.waiters)
    M.waiters := M.waiters - {T'}
    M.owner := T'
    wakeup(T')
 
Postconditions:
  - T is no longer the owner
  - Either M is unlocked, or a waiting thread is now the owner
 
 
SAFETY PROPERTY: Mutual Exclusion
─────────────────────────────────────────────────────
∀ time t:
  |{T : T is executing in critical section protected by M at time t}| ≤ 1
 
In plain language: At most one thread is ever in a given critical 
section at any point in time.

Undefined Behavior Territory

Attempting to unlock a mutex you don't own, or locking a mutex you already hold (for non-recursive mutexes), results in undefined behavior. The formal definition shows why: the preconditions are violated. In practice, this leads to deadlocks, data corruption, or crashes—often intermittent and difficult to debug.

Liveness Properties:

Beyond safety (mutual exclusion), a correct mutex implementation must also guarantee liveness—things eventually happen:

Progress: If the mutex is unlocked and threads are waiting, one thread must be granted the lock. The mutex must not remain unlocked indefinitely while threads wait.

Eventual Lock Acquisition (Bounded Waiting): Under fair scheduling, every waiting thread eventually acquires the lock. No thread starves forever.

Note: POSIX does not guarantee bounded waiting for mutexes—a thread may wait indefinitely if other threads continuously acquire and release the lock. However, most real-world implementations are sufficiently fair that starvation is rare in practice.

Ownership: The Distinguishing Feature

The concept of ownership is what fundamentally distinguishes a mutex from a binary semaphore. Understanding ownership is crucial for using mutexes correctly and avoiding subtle bugs.

What Ownership Means:

When thread T successfully acquires mutex M, T becomes the owner of M. This ownership establishes an exclusive relationship: only T may release M. This is enforced by the mutex implementation (at least in checked/debug modes).

Why Ownership Matters:

Benefits of Ownership Semantics

•Prevents Accidental Unlocking — Without ownership, any thread could unlock any mutex, leading to premature exposure of critical sections. With ownership, the system can detect and reject invalid unlock attempts.
•Enables Priority Inheritance — Ownership allows the scheduler to identify which thread is blocking high-priority waiters. The owner's priority can be temporarily boosted to prevent priority inversion.
•Supports Recursive Locking — Ownership tracking enables recursive mutexes, which allow the same thread to lock the same mutex multiple times (useful for reentrant code).
•Enables Deadlock Detection — By tracking which thread owns which mutex, the system can construct a wait-for graph and detect circular dependencies (deadlocks).
•Provides Debugging Information — When a deadlock or lock contention issue arises, knowing which thread owns which lock is essential for diagnosis.

ownership_violation.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#include <pthread.h>
#include <stdio.h>
 
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
 
void* thread_A(void* arg) {
    pthread_mutex_lock(&lock);
    printf("Thread A: Acquired lock
");
    
    // Thread A holds the lock...
    sleep(2);
    
    // Thread A SHOULD unlock here, but let's say it 'forgets'
    // and expects Thread B to do it (BUG!)
    
    return NULL;
}
 
void* thread_B(void* arg) {
    sleep(1);  // Let A acquire first
    
    // BUG: Thread B tries to unlock a lock it doesn't own
    // This is undefined behavior!
    pthread_mutex_unlock(&lock);  // <-- WRONG: B doesn't own this lock
    
    printf("Thread B: Attempting to unlock A's lock
");
    return NULL;
}
 
// BEHAVIOR:
// - On some systems: No error, lock is corrupted
// - On some systems: EPERM returned (if error checking enabled)
// - On some systems: Crash or hang
// 
// NEVER release a mutex you don't own!

The Cardinal Rule of Mutexes

Every lock() must be matched by an unlock() by THE SAME THREAD. The thread that acquired the mutex MUST be the one to release it. Violating this rule causes undefined behavior—your program may appear to work today and fail catastrophically tomorrow.

Ownership in Different Mutex Types:

POSIX defines different mutex types with varying ownership enforcement:

PTHREAD_MUTEX_NORMAL: No ownership checking. Unlocking from wrong thread is undefined behavior. Re-locking by owner causes deadlock.
PTHREAD_MUTEX_ERRORCHECK: Ownership is checked. Unlocking from wrong thread returns EPERM. Re-locking by owner returns EDEADLK.
PTHREAD_MUTEX_RECURSIVE: Ownership is tracked with a counter. Owner can lock multiple times (counter increments). Each lock must be balanced by an unlock.
PTHREAD_MUTEX_DEFAULT: Implementation-defined; typically behaves like NORMAL.

The Anatomy of Mutex Usage

Using a mutex correctly requires understanding a specific pattern that must be followed precisely. Deviations from this pattern lead to race conditions, deadlocks, or data corruption.

The Canonical Pattern:

mutex_canonical_pattern.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
// THE CORRECT MUTEX USAGE PATTERN
// This pattern must be followed EXACTLY
 
// 1. DECLARE: Create the mutex (once, before any use)
pthread_mutex_t guard = PTHREAD_MUTEX_INITIALIZER;
 
// 2. PROTECT: Surround critical section with lock/unlock
void protected_operation(void) {
    // ACQUIRE: Lock before accessing shared data
    pthread_mutex_lock(&guard);
    
    // CRITICAL SECTION: All shared data access happens here
    // The mutex guarantees only one thread is here at a time
    shared_data++;
    complex_shared_operation();
    
    // RELEASE: Unlock after finishing with shared data
    pthread_mutex_unlock(&guard);
}
 
// 3. CONSISTENT: ALL access to shared_data must use the same mutex
void another_operation(void) {
    pthread_mutex_lock(&guard);  // Same mutex!
    shared_data--;
    pthread_mutex_unlock(&guard);
}
 
// WRONG: Accessing shared_data without the mutex
void buggy_operation(void) {
    shared_data++;  // BUG: Unprotected access = race condition
}

Rules for Correct Mutex Usage

•Always pair lock and unlock — Every lock() must have a corresponding unlock(). Forgetting to unlock causes deadlock. Use RAII in C++ to automate this.
•Keep critical sections short — The longer you hold a lock, the more other threads are blocked. Do expensive operations outside the critical section when possible.
•Use the same mutex for the same data — All accesses to a piece of shared data must use the same mutex. Using different mutexes, or no mutex, for the same data causes races.
•Acquire locks in a consistent order — If you need multiple mutexes, always acquire them in the same order. Inconsistent ordering causes deadlock.
•Never unlock a mutex you don't own — Only the thread that acquired the mutex may release it. This is enforced by ownership semantics.
•Never access shared data outside the critical section — Even 'just a read' is unsafe. Reads during writes cause torn reads and data races.

The RAII Advantage

In C++, ALWAYS use std::lock_guard or std::unique_lock instead of raw lock()/unlock() calls. These RAII wrappers guarantee the lock is released even if an exception is thrown or you return early. This eliminates an entire class of bugs.

Memory Ordering and Visibility

A frequently overlooked aspect of mutexes is their role in memory ordering. Modern CPUs and compilers aggressively reorder instructions and cache memory accesses for performance. Without proper synchronization, threads may see stale or inconsistent data even when access patterns appear safe.

The Memory Visibility Problem:

Imagine Thread A writes to a variable, then Thread B reads it. Without synchronization, there is no guarantee that B sees A's write. The write might be sitting in A's CPU cache, not yet flushed to main memory. Or the compiler might have reordered A's write to occur after what appears to be the 'last' instruction.

How Mutexes Solve This:

Mutex lock and unlock operations act as memory barriers (also called fences). They enforce ordering constraints:

Memory Ordering Guarantees

•Acquire Semantics (lock()) — All memory operations AFTER the lock are guaranteed to happen AFTER the lock is acquired. No reads/writes can 'leak' upward past the lock.
•Release Semantics (unlock()) — All memory operations BEFORE the unlock are guaranteed to happen BEFORE the unlock. No reads/writes can 'leak' downward past the unlock.
•Combined Guarantee — When thread A unlocks and thread B subsequently locks the same mutex, all of A's writes before the unlock are visible to B after the lock. This is the 'happens-before' relationship.

memory_visibility_example.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// MEMORY VISIBILITY WITH MUTEXES
// 
// Without the mutex, data races cause undefined behavior.
// With the mutex, ordering is guaranteed.
 
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
int ready = 0;
int data = 0;
 
void producer(void) {
    // Prepare data (this write might be reordered by CPU/compiler)
    data = 42;
    
    // Mutex unlock has RELEASE semantics:
    // - Forces 'data = 42' to complete before unlock
    // - Makes data visible to any thread that acquires the lock
    pthread_mutex_lock(&lock);
    ready = 1;
    pthread_mutex_unlock(&lock);  // RELEASE barrier here
}
 
void consumer(void) {
    int local_data;
    
    // Mutex lock has ACQUIRE semantics:
    // - Any writes released by the previous holder are now visible
    pthread_mutex_lock(&lock);    // ACQUIRE barrier here
    if (ready) {
        // GUARANTEED: data = 42 is visible here
        // The mutex creates a "happens-before" relationship
        local_data = data;	
    }
    pthread_mutex_unlock(&lock);
}
 
// WITHOUT the mutex, 'data' might appear as 0 even after
// producer sets ready = 1 and data = 42. This is a data race.

Don't Rely on Volatile

In C/C++, the 'volatile' keyword does NOT provide memory ordering guarantees. It only prevents compiler optimizations, not CPU reorderings. For proper synchronization, you MUST use mutexes, atomics, or other synchronization primitives. This is a common misconception that leads to subtle, intermittent bugs.

Practical Implication:

The memory ordering guarantees of mutexes mean that you don't need to worry about CPU caches, store buffers, or compiler reordering—as long as you protect all shared data accesses with the same mutex. The mutex handles the low-level memory ordering for you.

This is why mutexes are the recommended synchronization primitive: they provide both mutual exclusion AND memory visibility in a single, well-understood abstraction.

Common Mutex Mistakes

Despite their simplicity, mutexes are frequently misused. Understanding common mistakes helps you avoid them in your own code and recognize them during code review.

Common Mutex Anti-Patterns

•Forgotten Unlock — Acquiring a lock but failing to release it, causing permanent deadlock
•Double Lock — Attempting to lock a mutex you already hold (deadlock for non-recursive)
•Mismatched Locks — Using different mutexes for the same shared data
•Lock Scope Too Large — Holding locks during I/O, sleep, or long computations
•Lock Ordering Violation — Acquiring multiple locks in inconsistent order

Best Practices

•Use RAII — Let destructors/defer handle unlock automatically
•Use Recursive Mutexes — Or refactor to avoid nested locking
•One Mutex Per Data — Associate each mutex with specific data
•Minimize Critical Sections — Do only essential work while holding lock
•Lock Hierarchy — Define and document a global lock ordering

mutex_mistakes.c
C (Bugs)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// BUG 1: Forgotten unlock on early return
void process_data(int* data) {
    pthread_mutex_lock(&lock);
    
    if (data == NULL) {
        return;  // BUG: Lock is never released!
    }
    
    // ... process data ...
    pthread_mutex_unlock(&lock);
}
 
// BUG 2: Exception without unlock (C++)
void risky_operation() {
    mutex.lock();
    may_throw_exception();  // If this throws, unlock never happens
    mutex.unlock();
}
 
// BUG 3: Wrong mutex for data
pthread_mutex_t lock_a, lock_b;
int shared_counter;
 
void increment() {
    pthread_mutex_lock(&lock_a);  // Using lock_a
    shared_counter++;
    pthread_mutex_unlock(&lock_a);
}
 
void decrement() {
    pthread_mutex_lock(&lock_b);  // BUG: Using lock_b for same data!
    shared_counter--;             // Race condition with increment()
    pthread_mutex_unlock(&lock_b);
}
 
// BUG 4: Deadlock from inconsistent ordering
void thread_1() {
    pthread_mutex_lock(&lock_a);  // Locks A first
    pthread_mutex_lock(&lock_b);  // Then B
    // ...
}
 
void thread_2() {
    pthread_mutex_lock(&lock_b);  // Locks B first
    pthread_mutex_lock(&lock_a);  // Then A -- DEADLOCK if concurrent!
    // ...
}

Tools for Finding Mutex Bugs

Use ThreadSanitizer (TSan) to detect data races at runtime. Use Helgrind or DRD (Valgrind tools) for lock order violations and potential deadlocks. Static analyzers like Clang's Thread Safety Analysis can catch many mutex bugs at compile time. Never rely on 'it works on my machine'—concurrency bugs are often intermittent.

Summary: The Mutex Concept

We have explored the mutex concept in depth—from its theoretical foundations to its practical usage patterns. Let's consolidate the key takeaways:

Key Takeaways

•A mutex provides mutual exclusion — The fundamental guarantee that only one thread can execute in a critical section at a time.
•Mutexes solve the critical section problem — They satisfy mutual exclusion, progress, and (with fair scheduling) bounded waiting.
•Ownership distinguishes mutexes from semaphores — Only the thread that acquired a mutex may release it. This enables priority inheritance and debugging.
•Lock and unlock operations are memory barriers — Mutexes ensure memory visibility between threads, not just exclusion.
•Correct usage follows a strict pattern — Always pair lock/unlock, use the same mutex for the same data, keep critical sections short.
•RAII is essential in C++ — Use std::lock_guard or std::unique_lock to guarantee unlock even in exceptional cases.

What's Next:

Now that we understand what a mutex is and why it exists, we need to examine the implementation choices. The next page explores the fundamental tradeoff at the heart of mutex implementation: blocking vs. spinning. Should a thread waiting for a mutex go to sleep (blocking), or should it keep checking in a loop (spinning)? The answer depends on expected wait time, critical section length, and system characteristics.

Page Complete

You now have a comprehensive understanding of the mutex concept—the foundational synchronization primitive in operating systems. You understand its theoretical basis, semantic properties, memory ordering guarantees, and correct usage patterns. Next, we'll explore how blocking vs. spinning affects mutex implementation and performance.