System Design (LLD)Synchronization Primitives

Synchronization Primitives: Coordinating Concurrent Access

LevelIntermediate

Duration90 mins

TopicSynchronization Primitives

4 / 4

Choosing Synchronization Mechanisms

The Right Tool for the Job

A craftsman's workshop contains many tools—hammers, screwdrivers, wrenches, pliers. Each serves a purpose; using the wrong one makes work harder and results worse. You could hammer a screw, but it's neither efficient nor effective.

Synchronization primitives are the same. Mutexes, semaphores, monitors, and their variants each excel in specific scenarios. Using a semaphore where a simple mutex suffices adds complexity. Using a mutex where a read-write lock fits sacrifices concurrency. Using spin locks where blocking locks are appropriate wastes CPU cycles.

Mastery means knowing not just how each tool works, but when to reach for it. This page synthesizes everything we've learned into a decision framework for selecting synchronization mechanisms.

What You Will Learn

By completing this page, you will have a systematic approach to selecting synchronization primitives, understand performance trade-offs between mechanisms, recognize patterns that indicate specific solutions, and be equipped to make informed decisions in real-world concurrent systems.

The Synchronization Landscape

Before choosing, let's survey the available options and their fundamental purposes:

Synchronization Primitive Overview
Primitive	Core Purpose	Key Characteristic	Typical Use Case
Mutex	Exclusive access	One holder at a time	Protecting shared state
Reentrant Lock	Exclusive access + nesting	Same thread can re-acquire	Recursive/callback scenarios
Spin Lock	Exclusive access (busy-wait)	No context switch	Very short critical sections
Read-Write Lock	Shared reads, exclusive writes	Multiple readers OR one writer	Read-heavy data structures
Binary Semaphore	Signaling between threads	No ownership concept	Event coordination
Counting Semaphore	Limited concurrent access	N simultaneous holders	Resource pools
Condition Variable	Wait for specific condition	Used with a lock	Complex coordination
Monitor	Lock + condition(s)	Structured synchronization	Producer-consumer, etc.
Barrier	N threads synchronize	All wait for each other	Phased algorithms
Latch	One-time signal	Opens once, stays open	Initialization gates

Beyond these primitives, modern languages offer higher-level abstractions built on these foundations:

Concurrent Collections: ConcurrentHashMap, BlockingQueue, etc.—internally synchronized
Atomic Variables: Lock-free primitives for simple operations
Thread Pools: Manage thread lifecycle and task queuing
Futures/Promises: Asynchronous result handling

Often, the right choice is a high-level abstraction rather than a raw primitive. Only drop down to primitives when abstractions don't fit.

Prefer High-Level Abstractions

Before reaching for a mutex, ask: 'Is there a concurrent collection that handles this?' Before writing a producer-consumer with semaphores, check if BlockingQueue exists. High-level abstractions are tested, optimized, and hide complexity. Only go lower when necessary.

Decision Framework

Use the following questions to guide your synchronization choice:

Key Questions

•What are you protecting? — Data? A resource pool? An event? A coordination point?
•How many threads need simultaneous access? — One (mutex), N (counting semaphore), unlimited readers (RW lock)?
•What's the access pattern? — All writes? Mostly reads? Mixed?
•How long is the critical section? — Nanoseconds (spin)? Microseconds (mutex)? Milliseconds (with I/O—reconsider design)?
•Is there conditional waiting involved? — Wait until queue non-empty? Wait for count to reach N?
•Can threads that lock also unlock, or is signaling decoupled? — Same thread (mutex) or different threads (semaphore)?
•Does the same thread need to re-acquire? — Reentrant scenarios (reentrant lock)?
•Is there a high-level abstraction available? — Concurrent collections? Thread-safe libraries?

The Decision Tree:

Follow this flowchart to arrive at the appropriate mechanism:

decision-tree.txt
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
START: What do you need to synchronize?
 
├── Protecting shared data from concurrent modification?
│   ├── Read-heavy workload (>80% reads)?
│   │   └── → Read-Write Lock
│   ├── Critical section < 1 microsecond AND multi-core?
│   │   └── → Spin Lock
│   ├── Same thread might re-enter?
│   │   └── → Reentrant Lock
│   └── General exclusive access?
│       └── → Mutex
│
├── Limiting concurrent access to N resources?
│   ├── N = 1 AND any thread can release?
│   │   └── → Binary Semaphore
│   └── N > 1 (pool, rate limit, etc.)?
│       └── → Counting Semaphore
│
├── Signaling between threads?
│   ├── One thread signals, another waits?
│   │   └── → Binary Semaphore (or Condition Variable)
│   ├── Wait for N events before proceeding?
│   │   └── → Countdown Latch
│   └── N threads must all reach a point together?
│       └── → Barrier
│
├── Waiting for a specific condition?
│   ├── "Wait until queue not empty"
│   │   └── → Monitor (Lock + Condition Variable)
│   └── "Wait until resource available from pool"
│       └── → Semaphore (simpler than monitor)
│
└── Complex coordination involving multiple conditions?
    └── → Monitor with multiple Condition Variables

Pattern Recognition: Matching Problems to Primitives

Expert engineers recognize synchronization patterns instantly. Here's a catalog of common patterns and their preferred solutions:

Critical Section Scenarios
Scenario	Indicators	Recommended Primitive	Why
Simple shared counter	Increment/decrement only	Atomic variable	Lock-free, highest performance
Complex state update	Multiple fields, invariants	Mutex	Atomicity across operations
Recursive data structure	Tree traversal with modification	Reentrant Lock	Same thread may re-enter
In-memory cache	Frequent reads, rare writes	Read-Write Lock	Concurrent reads, exclusive writes
Lock-free data structure	Expert implementation	Atomic CAS operations	Maximum concurrency, complex

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Pattern: Simple counter → Atomic variable
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();  // Lock-free
 
// Pattern: Complex state → Mutex
class Account {
    private final Lock lock = new ReentrantLock();
    private double balance;
    private List<Transaction> history;
    
    void transfer(double amount, Account target) {
        lock.lock();
        try {
            balance -= amount;
            history.add(new Transaction(-amount));
            // Invariant: balance + sum(history) = initial
        } finally {
            lock.unlock();
        }
    }
}

Performance Trade-offs

Choosing synchronization isn't just about correctness—performance matters too. Here's how primitives compare under different conditions:

Performance Characteristics
Primitive	Uncontended Latency	Contended Behavior	Scalability	Memory Overhead
Atomic Variable	~5-10 ns	CAS retry loop	Excellent	Minimal (word-sized)
Spin Lock	~5-10 ns	Burns CPU	Poor under contention	Minimal
Mutex	~20-50 ns	Context switch	Good	Low (~40 bytes)
Reentrant Lock	~25-60 ns	Context switch	Good	Medium (~50 bytes)
Read-Write Lock	~30-70 ns	Readers parallel	Excellent for reads	Medium
Semaphore	~20-50 ns	Context switch	Good	Low
Condition Variable	~30-60 ns	Context switch	Good	Low

Key Performance Insights:

•Contention dominates: Uncontended costs are nearly equal. The real difference shows under contention.
•Spin locks are a trap: They seem fast but can devastate throughput under contention—CPU cycles wasted spinning.
•Read-write locks break even around 80% reads: Below that, the overhead exceeds the concurrency benefit.
•Atomics scale best: For simple operations (counters, flags), atomic variables beat all locks.
•Context switches cost ~1-10 μs: If your critical section is shorter, consider spinning briefly before sleeping.
•Cache effects matter: Locks cause memory barriers that flush caches—nearby data operations slow down too.

Profile Before Optimizing

These numbers are rough guidelines. Actual performance depends on your workload, contention level, and hardware. Always profile with realistic load before choosing 'faster' primitives. A slightly slower but simpler solution often wins in maintainability.

adaptive-spinning.java
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
// Modern JVMs use adaptive spinning internally
// This shows the concept (don't implement yourself)
 
class AdaptiveLock {
    private static final int MAX_SPIN = 1000;
    private final AtomicBoolean locked = new AtomicBoolean(false);
    
    void lock() {
        // Phase 1: Brief spin (no context switch)
        for (int i = 0; i < MAX_SPIN; i++) {
            if (locked.compareAndSet(false, true)) {
                return;  // Acquired without sleeping
            }
            Thread.onSpinWait();  // Hint to CPU
        }
        
        // Phase 2: Failed to acquire by spinning, go to sleep
        while (!locked.compareAndSet(false, true)) {
            LockSupport.park();  // Sleep (context switch)
        }
    }
    
    void unlock() {
        locked.set(false);
        LockSupport.unpark(someWaiter);  // Wake a sleeper
    }
}

Real-World Case Studies

Let's apply the decision framework to real scenarios, walking through the reasoning:

Scenario: Track total requests served by a web server across all handler threads.

Analysis:

What? A simple counter (integer)
How many writers? Many (all request threads)
How many readers? Few (metrics endpoint)
Critical section? Increment operation only

Decision: Atomic variable (AtomicLong)

Why not mutex? The increment is a single operation. AtomicLong.incrementAndGet() is lock-free and scales to hundreds of concurrent threads without contention.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class RequestCounter {
    // ✓ Atomic - scales perfectly
    private final AtomicLong count = new AtomicLong(0);
    
    void recordRequest() {
        count.incrementAndGet();  // Lock-free
    }
    
    long getCount() {
        return count.get();
    }
}
 
// ✗ Mutex - unnecessary overhead
class SlowRequestCounter {
    private final ReentrantLock lock = new ReentrantLock();
    private long count = 0;
    
    void recordRequest() {
        lock.lock();
        try { count++; }
        finally { lock.unlock(); }
    }
}

Anti-Patterns to Avoid

Poor synchronization choices cause subtle bugs, performance problems, and maintenance nightmares. Recognize and avoid these anti-patterns:

Anti-Pattern: Over-Synchronization

Wrapping everything in locks 'just to be safe'. Results in serialized execution—might as well be single-threaded. Loss of concurrency benefit.

Anti-Pattern: Wrong Granularity

One lock for the entire object when multiple independent fields exist. All operations serialize, even non-conflicting ones.

Anti-Pattern: Spin Lock Everywhere

Using spin locks because they're 'faster'. Under contention, spinners burn CPU while holder can't run—performance collapse.

Anti-Pattern: Read-Write Lock for Write-Heavy

Read-write lock has higher overhead than mutex. If writes are frequent, the concurrency gain from parallel reads doesn't offset the cost.

Anti-Pattern: Primitive When Abstraction Exists

Building a blocking queue from semaphores when BlockingQueue is in the standard library. Reinventing, with bugs.

Anti-Pattern: Lock Inside a Loop

Acquiring and releasing a lock repeatedly in a tight loop. Lock overhead per iteration dominates actual work.

anti-pattern.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ✗ ANTI-PATTERN: Lock in loop
void processItems(List<Item> items) {
    for (Item item : items) {
        lock.lock();
        try {
            process(item);  // Lock/unlock per item!
        } finally {
            lock.unlock();
        }
    }
}
 
// Many lock/unlock cycles
// High overhead dominates

correct-pattern.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ✓ CORRECT: Lock outside loop
void processItems(List<Item> items) {
    lock.lock();
    try {
        for (Item item : items) {
            process(item);
        }
    } finally {
        lock.unlock();  // Once!
    }
}
 
// One lock/unlock cycle
// Minimal overhead

Quick Reference Guide

Use this cheat sheet when facing synchronization decisions:

When to Use Each Primitive
If You Need To...	Use	Example
Increment/decrement a counter	Atomic Variable	`AtomicLong.incrementAndGet()`
Protect complex state from concurrent access	Mutex / ReentrantLock	Bank account transfer
Allow multiple readers, single writer	Read-Write Lock	Configuration cache
Limit concurrent access to N resources	Counting Semaphore	Connection pool
Signal between unrelated threads	Binary Semaphore	Producer signals consumer
Wait for a specific condition	Monitor (Lock + Condition)	Wait until queue non-empty
Wait for N threads to assemble	Barrier	Parallel algorithm phases
Wait for N events to complete	Countdown Latch	Service initialization
Execute task in thread pool	Use high-level ExecutorService	Task scheduling
Manage async result	Future / CompletableFuture	Async computation result

The Golden Rule

Start with the highest-level abstraction that fits. Only drop down to lower-level primitives when you need control that abstractions don't provide. Simple, readable code is usually better than clever, 'optimized' code—especially in concurrency where bugs are hard to find.

Summary: Choosing Synchronization Mechanisms

We've built a comprehensive framework for selecting synchronization primitives. Here are the key takeaways:

Key Takeaways

•Match primitives to requirements — Mutex for exclusion, semaphore for counting, monitor for conditions
•Prefer high-level abstractions — BlockingQueue over manual semaphores, ConcurrentHashMap over RW locks
•Consider access patterns — Read-heavy → RW lock; write-heavy → mutex; simple ops → atomics
•Spin locks are rarely right — Only for sub-microsecond critical sections on multi-core systems
•Profile before optimizing — Correctness first, then measure, then optimize if needed
•Avoid common anti-patterns — Over-synchronization, wrong granularity, lock-in-loop

Module Complete:

You've now mastered synchronization primitives—from the mechanics of mutexes, semaphores, and monitors to the judgment of when to apply each. This knowledge forms the foundation for building robust concurrent systems.

The next module on Deadlocks and Prevention will explore what happens when synchronization goes wrong and how to design systems that never get stuck.

Module Complete

Congratulations! You now have a systematic approach to choosing synchronization mechanisms. You can analyze requirements, recognize patterns, and select appropriate primitives. You understand performance trade-offs and can avoid common mistakes. You're ready to tackle the challenges of deadlock prevention in the next module.

4 / 4

Loading learning content...

System Design (LLD)Synchronization Primitives

Synchronization Primitives: Coordinating Concurrent Access

LevelIntermediate

Duration90 mins

TopicSynchronization Primitives

4 / 4

Choosing Synchronization Mechanisms

The Right Tool for the Job

Mastery means knowing not just how each tool works, but when to reach for it. This page synthesizes everything we've learned into a decision framework for selecting synchronization mechanisms.

What You Will Learn

The Synchronization Landscape

Before choosing, let's survey the available options and their fundamental purposes:

Synchronization Primitive Overview
Primitive	Core Purpose	Key Characteristic	Typical Use Case
Mutex	Exclusive access	One holder at a time	Protecting shared state
Reentrant Lock	Exclusive access + nesting	Same thread can re-acquire	Recursive/callback scenarios
Spin Lock	Exclusive access (busy-wait)	No context switch	Very short critical sections
Read-Write Lock	Shared reads, exclusive writes	Multiple readers OR one writer	Read-heavy data structures
Binary Semaphore	Signaling between threads	No ownership concept	Event coordination
Counting Semaphore	Limited concurrent access	N simultaneous holders	Resource pools
Condition Variable	Wait for specific condition	Used with a lock	Complex coordination
Monitor	Lock + condition(s)	Structured synchronization	Producer-consumer, etc.
Barrier	N threads synchronize	All wait for each other	Phased algorithms
Latch	One-time signal	Opens once, stays open	Initialization gates

Beyond these primitives, modern languages offer higher-level abstractions built on these foundations:

Concurrent Collections: ConcurrentHashMap, BlockingQueue, etc.—internally synchronized
Atomic Variables: Lock-free primitives for simple operations
Thread Pools: Manage thread lifecycle and task queuing
Futures/Promises: Asynchronous result handling

Often, the right choice is a high-level abstraction rather than a raw primitive. Only drop down to primitives when abstractions don't fit.

Prefer High-Level Abstractions

Decision Framework

Use the following questions to guide your synchronization choice:

Key Questions

•What are you protecting? — Data? A resource pool? An event? A coordination point?
•How many threads need simultaneous access? — One (mutex), N (counting semaphore), unlimited readers (RW lock)?
•What's the access pattern? — All writes? Mostly reads? Mixed?
•How long is the critical section? — Nanoseconds (spin)? Microseconds (mutex)? Milliseconds (with I/O—reconsider design)?
•Is there conditional waiting involved? — Wait until queue non-empty? Wait for count to reach N?
•Can threads that lock also unlock, or is signaling decoupled? — Same thread (mutex) or different threads (semaphore)?
•Does the same thread need to re-acquire? — Reentrant scenarios (reentrant lock)?
•Is there a high-level abstraction available? — Concurrent collections? Thread-safe libraries?

The Decision Tree:

Follow this flowchart to arrive at the appropriate mechanism:

decision-tree.txt
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
START: What do you need to synchronize?
 
├── Protecting shared data from concurrent modification?
│   ├── Read-heavy workload (>80% reads)?
│   │   └── → Read-Write Lock
│   ├── Critical section < 1 microsecond AND multi-core?
│   │   └── → Spin Lock
│   ├── Same thread might re-enter?
│   │   └── → Reentrant Lock
│   └── General exclusive access?
│       └── → Mutex
│
├── Limiting concurrent access to N resources?
│   ├── N = 1 AND any thread can release?
│   │   └── → Binary Semaphore
│   └── N > 1 (pool, rate limit, etc.)?
│       └── → Counting Semaphore
│
├── Signaling between threads?
│   ├── One thread signals, another waits?
│   │   └── → Binary Semaphore (or Condition Variable)
│   ├── Wait for N events before proceeding?
│   │   └── → Countdown Latch
│   └── N threads must all reach a point together?
│       └── → Barrier
│
├── Waiting for a specific condition?
│   ├── "Wait until queue not empty"
│   │   └── → Monitor (Lock + Condition Variable)
│   └── "Wait until resource available from pool"
│       └── → Semaphore (simpler than monitor)
│
└── Complex coordination involving multiple conditions?
    └── → Monitor with multiple Condition Variables

Pattern Recognition: Matching Problems to Primitives

Expert engineers recognize synchronization patterns instantly. Here's a catalog of common patterns and their preferred solutions:

Critical Section Scenarios
Scenario	Indicators	Recommended Primitive	Why
Simple shared counter	Increment/decrement only	Atomic variable	Lock-free, highest performance
Complex state update	Multiple fields, invariants	Mutex	Atomicity across operations
Recursive data structure	Tree traversal with modification	Reentrant Lock	Same thread may re-enter
In-memory cache	Frequent reads, rare writes	Read-Write Lock	Concurrent reads, exclusive writes
Lock-free data structure	Expert implementation	Atomic CAS operations	Maximum concurrency, complex

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Pattern: Simple counter → Atomic variable
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();  // Lock-free
 
// Pattern: Complex state → Mutex
class Account {
    private final Lock lock = new ReentrantLock();
    private double balance;
    private List<Transaction> history;
    
    void transfer(double amount, Account target) {
        lock.lock();
        try {
            balance -= amount;
            history.add(new Transaction(-amount));
            // Invariant: balance + sum(history) = initial
        } finally {
            lock.unlock();
        }
    }
}

Performance Trade-offs

Choosing synchronization isn't just about correctness—performance matters too. Here's how primitives compare under different conditions:

Performance Characteristics
Primitive	Uncontended Latency	Contended Behavior	Scalability	Memory Overhead
Atomic Variable	~5-10 ns	CAS retry loop	Excellent	Minimal (word-sized)
Spin Lock	~5-10 ns	Burns CPU	Poor under contention	Minimal
Mutex	~20-50 ns	Context switch	Good	Low (~40 bytes)
Reentrant Lock	~25-60 ns	Context switch	Good	Medium (~50 bytes)
Read-Write Lock	~30-70 ns	Readers parallel	Excellent for reads	Medium
Semaphore	~20-50 ns	Context switch	Good	Low
Condition Variable	~30-60 ns	Context switch	Good	Low

Key Performance Insights:

•Contention dominates: Uncontended costs are nearly equal. The real difference shows under contention.
•Spin locks are a trap: They seem fast but can devastate throughput under contention—CPU cycles wasted spinning.
•Read-write locks break even around 80% reads: Below that, the overhead exceeds the concurrency benefit.
•Atomics scale best: For simple operations (counters, flags), atomic variables beat all locks.
•Context switches cost ~1-10 μs: If your critical section is shorter, consider spinning briefly before sleeping.
•Cache effects matter: Locks cause memory barriers that flush caches—nearby data operations slow down too.

Profile Before Optimizing

adaptive-spinning.java
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
// Modern JVMs use adaptive spinning internally
// This shows the concept (don't implement yourself)
 
class AdaptiveLock {
    private static final int MAX_SPIN = 1000;
    private final AtomicBoolean locked = new AtomicBoolean(false);
    
    void lock() {
        // Phase 1: Brief spin (no context switch)
        for (int i = 0; i < MAX_SPIN; i++) {
            if (locked.compareAndSet(false, true)) {
                return;  // Acquired without sleeping
            }
            Thread.onSpinWait();  // Hint to CPU
        }
        
        // Phase 2: Failed to acquire by spinning, go to sleep
        while (!locked.compareAndSet(false, true)) {
            LockSupport.park();  // Sleep (context switch)
        }
    }
    
    void unlock() {
        locked.set(false);
        LockSupport.unpark(someWaiter);  // Wake a sleeper
    }
}

Real-World Case Studies

Let's apply the decision framework to real scenarios, walking through the reasoning:

Scenario: Track total requests served by a web server across all handler threads.

Analysis:

What? A simple counter (integer)
How many writers? Many (all request threads)
How many readers? Few (metrics endpoint)
Critical section? Increment operation only

Decision: Atomic variable (AtomicLong)

Why not mutex? The increment is a single operation. AtomicLong.incrementAndGet() is lock-free and scales to hundreds of concurrent threads without contention.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class RequestCounter {
    // ✓ Atomic - scales perfectly
    private final AtomicLong count = new AtomicLong(0);
    
    void recordRequest() {
        count.incrementAndGet();  // Lock-free
    }
    
    long getCount() {
        return count.get();
    }
}
 
// ✗ Mutex - unnecessary overhead
class SlowRequestCounter {
    private final ReentrantLock lock = new ReentrantLock();
    private long count = 0;
    
    void recordRequest() {
        lock.lock();
        try { count++; }
        finally { lock.unlock(); }
    }
}

Anti-Patterns to Avoid

Poor synchronization choices cause subtle bugs, performance problems, and maintenance nightmares. Recognize and avoid these anti-patterns:

Anti-Pattern: Over-Synchronization

Wrapping everything in locks 'just to be safe'. Results in serialized execution—might as well be single-threaded. Loss of concurrency benefit.

Anti-Pattern: Wrong Granularity

One lock for the entire object when multiple independent fields exist. All operations serialize, even non-conflicting ones.

Anti-Pattern: Spin Lock Everywhere

Using spin locks because they're 'faster'. Under contention, spinners burn CPU while holder can't run—performance collapse.

Anti-Pattern: Read-Write Lock for Write-Heavy

Read-write lock has higher overhead than mutex. If writes are frequent, the concurrency gain from parallel reads doesn't offset the cost.

Anti-Pattern: Primitive When Abstraction Exists

Building a blocking queue from semaphores when BlockingQueue is in the standard library. Reinventing, with bugs.

Anti-Pattern: Lock Inside a Loop

Acquiring and releasing a lock repeatedly in a tight loop. Lock overhead per iteration dominates actual work.

anti-pattern.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ✗ ANTI-PATTERN: Lock in loop
void processItems(List<Item> items) {
    for (Item item : items) {
        lock.lock();
        try {
            process(item);  // Lock/unlock per item!
        } finally {
            lock.unlock();
        }
    }
}
 
// Many lock/unlock cycles
// High overhead dominates

correct-pattern.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ✓ CORRECT: Lock outside loop
void processItems(List<Item> items) {
    lock.lock();
    try {
        for (Item item : items) {
            process(item);
        }
    } finally {
        lock.unlock();  // Once!
    }
}
 
// One lock/unlock cycle
// Minimal overhead

Quick Reference Guide

Use this cheat sheet when facing synchronization decisions:

When to Use Each Primitive
If You Need To...	Use	Example
Increment/decrement a counter	Atomic Variable	`AtomicLong.incrementAndGet()`
Protect complex state from concurrent access	Mutex / ReentrantLock	Bank account transfer
Allow multiple readers, single writer	Read-Write Lock	Configuration cache
Limit concurrent access to N resources	Counting Semaphore	Connection pool
Signal between unrelated threads	Binary Semaphore	Producer signals consumer
Wait for a specific condition	Monitor (Lock + Condition)	Wait until queue non-empty
Wait for N threads to assemble	Barrier	Parallel algorithm phases
Wait for N events to complete	Countdown Latch	Service initialization
Execute task in thread pool	Use high-level ExecutorService	Task scheduling
Manage async result	Future / CompletableFuture	Async computation result

The Golden Rule

Summary: Choosing Synchronization Mechanisms

We've built a comprehensive framework for selecting synchronization primitives. Here are the key takeaways:

Key Takeaways

•Match primitives to requirements — Mutex for exclusion, semaphore for counting, monitor for conditions
•Prefer high-level abstractions — BlockingQueue over manual semaphores, ConcurrentHashMap over RW locks
•Consider access patterns — Read-heavy → RW lock; write-heavy → mutex; simple ops → atomics
•Spin locks are rarely right — Only for sub-microsecond critical sections on multi-core systems
•Profile before optimizing — Correctness first, then measure, then optimize if needed
•Avoid common anti-patterns — Over-synchronization, wrong granularity, lock-in-loop

Module Complete:

The next module on Deadlocks and Prevention will explore what happens when synchronization goes wrong and how to design systems that never get stuck.

Module Complete

4 / 4