{"title":"Mutex (Mutual Exclusion)","description":"","content":"A **mutex (mutual exclusion)** is the most fundamental synchronization primitive. It ensures that only one thread can access a critical section at a time. Once you understand mutexes, you have the building block for almost every other synchronization mechanism.\n\nThis chapter covers what a mutex is, how mutexes work, and how to use them correctly.\n\n---\n\n# What is a Mutex?\n\n\n> **Real-World Analogy**\n>\n> Think of a bank with a single key to a private safety deposit box room. When a customer arrives, they take the key from the front desk, enter the room, and do whatever they need with the boxes inside. If another customer arrives while the first is inside, they have to wait at the desk until the key is returned. \n>\n> The crucial detail: the person who took the key must be the one to return it. You cannot send someone else to hand it back.\n\n\nIn programming terms, a mutex is a synchronization primitive that provides mutual exclusion. When a thread acquires (locks) a mutex, any other thread that tries to acquire the same mutex will block until the first thread releases (unlocks) it. The thread that locks must be the one to unlock.\n\n\n```mermaid\nstateDiagram-v2\n [*] --> Unlocked: Initial state\n\n Unlocked --> Locked: Thread A acquires\n Locked --> Unlocked: Thread A releases\n\n Locked --> Waiting: Thread B tries to acquire\n Waiting --> Locked: Thread A releases,
Thread B acquires\n\n classDef unlocked fill:#69db7c,stroke:#000,color:#000\n classDef locked fill:#ff8787,stroke:#000,color:#000\n classDef waiting fill:#ffa94d,stroke:#000,color:#000\n\n class Unlocked unlocked\n class Locked locked\n class Waiting waiting\n```\n\n\nThe diagram above captures the lifecycle of a mutex. It starts in the **Unlocked** state (green), meaning no thread currently holds it. When Thread A calls `lock()`, the mutex transitions to **Locked** (red). Now if Thread B tries to acquire it, Thread B cannot proceed. Instead, it enters a **Waiting** state (orange), blocked until the mutex becomes available again. \n\nOnce Thread A calls `unlock()`, the mutex releases and Thread B can finally acquire it, transitioning back to the Locked state with a new owner. This cycle repeats as threads take turns accessing the protected resource.\n\nThe key properties of a mutex:\n\n- **Mutual Exclusion:** At most one thread can hold the mutex at any time\n- **Ownership:** The thread that locks the mutex must be the one to unlock it\n- **Blocking:** Threads that can't acquire the mutex are suspended until it becomes available\n\n### The Problem Mutex Solves: Critical Sections\n\nA **critical section** is any piece of code that reads or writes **shared state** and must not be executed by more than one thread at the same time. If two threads enter that section together, you can end up with **race conditions**, where the final result depends on timing rather than logic.\n\nA classic example is incrementing a shared counter.\n\nImagine `counter = 0`, and two threads execute `counter++` at the same time. Even though `counter++` looks like a single operation, it is actually a sequence of steps:\n\n1. read the current value\n2. compute the new value (add 1)\n3. write the new value back\n\nNow watch what can go wrong:\n\n\n```plaintext\nThread A: read counter (0)\nThread B: read counter (0)\nThread A: increment to 1\nThread B: increment to 1\nThread A: write counter (1)\nThread B: write counter (1)\nFinal value: 1 (should be 2!)\n```\n\n\nBoth threads started from the same old value, did correct math, and still produced the wrong result because they overwrote each other’s update. This is called a **lost update**, and it is one of the most common concurrency bugs.\n\nA **mutex** (mutual exclusion lock) prevents this by ensuring only one thread can execute the critical section at a time. If Thread A holds the lock, Thread B must wait until Thread A exits and releases it. That turns the critical section into an atomic, safe operation from the perspective of other threads.\n\nLet us now look at how mutex works under the hood.\n\n---\n\n# How Mutex Works\n\n\n\n\n\nA mutex (mutual exclusion lock) is the simplest and most common way to protect a critical section. The idea is straightforward: **at most one thread can hold the lock at a time**. Everyone else must wait.\n\nHere’s what happens when a thread wants to enter a critical section.\n\n1. **Attempt to acquire:** Thread checks if the mutex is available\n2. **If available:** Thread sets the mutex to \"locked\" and enters the critical section\n3. **If not available:** Thread is put into a **wait queue** and **blocked**, so it stops using CPU\n4. **On release:** The mutex is set to \"unlocked\" and one waiting thread is woken up\n5. **Woken thread:** Attempts acquisition again (may compete with others)\n\n\n```mermaid\nflowchart TD\n START[Thread wants to enter
critical section]:::primary --> CHECK{Mutex
available?}:::decision\n CHECK --> |Yes| ACQUIRE[Acquire mutex
Set to locked]:::green\n CHECK --> |No| BLOCK[Block thread
Add to wait queue]:::orange\n\n ACQUIRE --> CRITICAL[Execute
critical section]:::green\n CRITICAL --> RELEASE[Release mutex
Set to unlocked]:::green\n RELEASE --> WAKE{Waiting
threads?}:::decision\n WAKE --> |Yes| NOTIFY[Wake one thread]:::purple\n WAKE --> |No| DONE[Done]:::secondary\n NOTIFY --> DONE\n\n BLOCK --> |Woken| CHECK\n\n\tclassDef decision fill:#ffd43b,stroke:#000,color:#000\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef purple fill:#9775fa,stroke:#000,color:#000\n```\n\n\nAfter the critical section completes, the thread releases the mutex. This is where the wake-up mechanism kicks in: if any threads are waiting, one of them gets notified. That woken thread loops back to the availability check and attempts acquisition again. \n\nNote that it might compete with other threads that arrived in the meantime, so waking up does not guarantee immediate acquisition, just another chance to try.\n\n### Key Operations\n\n\n| Operation | Description | Blocking? |\n|-----------|-------------|-----------|\n| `lock()` / `acquire()` | Acquire the mutex; block if unavailable | Yes |\n| `unlock()` / `release()` | Release the mutex; wake waiting threads | No |\n| `tryLock()` / `try_lock()` | Try to acquire; return immediately with success/failure | No |\n| `tryLock(timeout)` | Try to acquire with timeout; return success/failure | Yes (up to timeout) |\n\n\n### Sequence of Two Threads\n\n\n```mermaid\nsequenceDiagram\n participant T1 as Thread 1\n participant M as Mutex\n participant T2 as Thread 2\n\n T1->>M: lock()\n M-->>T1: acquired\n Note over T1: critical section\n\n T2->>M: lock()\n Note over T2: blocked (waiting)\n\n T1->>M: unlock()\n M-->>T2: acquired\n Note over T2: critical section\n\n T2->>M: unlock()\n```\n\n\n1. **Thread 1** calls `lock()` → acquires the mutex → enters critical section\n2. **Thread 2** calls `lock()` → mutex is taken → Thread 2 blocks and waits\n3. **Thread 1** calls `unlock()` → releases the mutex → wakes a waiter\n4. **Thread 2** wakes → successfully acquires → enters critical section → later unlocks\n\nWhat you get is **serialized access**: even if both threads are available and the machine has multiple cores, only one thread can be inside the protected code at a time. Only when T1 calls `unlock()` does T2 finally get to acquire the mutex and enter its own critical section. \n\n---\n\n# Implementing Mutex\n\nThe implementation patterns here apply whether you are protecting a simple counter or a complex data structure.\n\n### Basic Usage\n\n\n#### Java\n\nIn Java, you typically use one of two approaches:\n\n- `synchronized` (intrinsic monitor lock, built into the language)\n- `Lock` implementations like `ReentrantLock` (explicit locks from `java.util.concurrent.locks`)\n\nBoth provide mutual exclusion. The difference is mostly about **simplicity vs control**.\n\n\n```java\nimport java.util.concurrent.locks.Lock;\nimport java.util.concurrent.locks.ReentrantLock;\n\npublic class Counter {\n private int count = 0;\n private final Lock lock = new ReentrantLock();\n\n // Approach 1: Explicit lock\n public void incrementWithLock() {\n lock.lock();\n try {\n count++;\n } finally {\n lock.unlock(); // Always in finally!\n }\n }\n\n // Approach 2: synchronized method\n public synchronized void incrementSynchronized() {\n count++;\n }\n\n // Approach 3: synchronized block\n public void incrementWithBlock() {\n synchronized (this) {\n count++;\n }\n }\n\n public int getCount() {\n lock.lock();\n try {\n return count;\n } finally {\n lock.unlock();\n }\n }\n}\n```\n\n\nThe try-finally pattern is non-negotiable when using explicit locks. Notice that `lock.lock()` comes *before* the try block. If you put it inside, an exception during locking would trigger the finally block and try to unlock a lock you never acquired. \n\nThe `synchronized` keyword handles this automatically, which is why Approach 2 and 3 look cleaner. The trade-off: `ReentrantLock` gives you features like `tryLock()` and fairness policies that `synchronized` cannot provide.\n\n\n---\n\n# Complete Example: Thread-Safe Counter\n\nLet us put everything together with a complete, runnable example. We will create 10 threads, each incrementing a shared counter 1,000 times. Without a mutex, the final count would be some random number less than 10,000 due to lost updates. With the mutex, we get exactly 10,000 every single time.\n\n\n```java\nimport java.util.concurrent.locks.ReentrantLock;\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class ThreadSafeCounterDemo {\n public static void main(String[] args) throws InterruptedException {\n Counter counter = new Counter();\n List threads = new ArrayList<>();\n\n // Create 10 threads, each incrementing 1000 times\n for (int i = 0; i < 10; i++) {\n Thread t = new Thread(() -> {\n for (int j = 0; j < 1000; j++) {\n counter.increment();\n }\n });\n threads.add(t);\n t.start();\n }\n\n // Wait for all threads\n for (Thread t : threads) {\n t.join();\n }\n\n System.out.println(\"Final count: \" + counter.getCount());\n }\n}\n\nclass Counter {\n private int count = 0;\n private final ReentrantLock lock = new ReentrantLock();\n\n public void increment() {\n lock.lock();\n try {\n count++;\n } finally {\n lock.unlock();\n }\n }\n\n public int getCount() {\n lock.lock();\n try {\n return count;\n } finally {\n lock.unlock();\n }\n }\n}\n```\n\n```python\nimport threading\n\nclass Counter:\n def __init__(self):\n self.count = 0\n self.lock = threading.Lock()\n\n def increment(self):\n with self.lock:\n self.count += 1\n\n def get_count(self):\n with self.lock:\n return self.count\n\ndef worker(counter, iterations):\n for _ in range(iterations):\n counter.increment()\n\ndef main():\n counter = Counter()\n threads = []\n\n # Create 10 threads, each incrementing 1000 times\n for _ in range(10):\n t = threading.Thread(target=worker, args=(counter, 1000))\n threads.append(t)\n t.start()\n\n # Wait for all threads\n for t in threads:\n t.join()\n\n print(f\"Final count: {counter.get_count()}\")\n\nif __name__ == \"__main__\":\n main()\n```\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass Counter {\n int count = 0;\n std::mutex mtx;\n\npublic:\n void increment() {\n std::lock_guard lock(mtx);\n count++;\n }\n\n int getCount() {\n std::lock_guard lock(mtx);\n return count;\n }\n};\n\nint main() {\n Counter counter;\n std::vector threads;\n\n // Create 10 threads, each incrementing 1000 times\n for (int i = 0; i < 10; i++) {\n threads.emplace_back([&counter]() {\n for (int j = 0; j < 1000; j++) {\n counter.increment();\n }\n });\n }\n\n // Wait for all threads\n for (auto& t : threads) {\n t.join();\n }\n\n std::cout << \"Final count: \" << counter.getCount() << std::endl;\n return 0;\n}\n```\n\n```csharp\nusing System;\nusing System.Collections.Generic;\nusing System.Threading;\n\npublic class ThreadSafeCounterDemo\n{\n public static void Main()\n {\n Counter counter = new Counter();\n List threads = new List();\n\n // Create 10 threads, each incrementing 1000 times\n for (int i = 0; i < 10; i++)\n {\n Thread t = new Thread(() =>\n {\n for (int j = 0; j < 1000; j++)\n {\n counter.Increment();\n }\n });\n threads.Add(t);\n t.Start();\n }\n\n // Wait for all threads\n foreach (Thread t in threads)\n {\n t.Join();\n }\n\n Console.WriteLine($\"Final count: {counter.GetCount()}\");\n }\n}\n\npublic class Counter\n{\n private int count = 0;\n private readonly object lockObj = new object();\n\n public void Increment()\n {\n lock (lockObj)\n {\n count++;\n }\n }\n\n public int GetCount()\n {\n lock (lockObj)\n {\n return count;\n }\n }\n}\n```\n\n```go\npackage main\n\nimport (\n \"fmt\"\n \"sync\"\n)\n\ntype Counter struct {\n mu sync.Mutex\n count int\n}\n\nfunc (c *Counter) Increment() {\n c.mu.Lock()\n defer c.mu.Unlock()\n c.count++\n}\n\nfunc (c *Counter) GetCount() int {\n c.mu.Lock()\n defer c.mu.Unlock()\n return c.count\n}\n\nfunc main() {\n counter := &Counter{}\n var wg sync.WaitGroup\n\n // Create 10 goroutines, each incrementing 1000 times\n for i := 0; i < 10; i++ {\n wg.Add(1)\n go func() {\n defer wg.Done()\n for j := 0; j < 1000; j++ {\n counter.Increment()\n }\n }()\n }\n\n // Wait for all goroutines\n wg.Wait()\n\n fmt.Printf(\"Final count: %d\\n\", counter.GetCount())\n}\n```\n\n\nWithout the mutex, this number would be unpredictable, often landing somewhere between 5,000 and 9,000 depending on timing. The mutex ensures that each increment operation, the read-modify-write sequence, completes atomically from the perspective of other threads. Ten threads times one thousand increments equals exactly ten thousand, guaranteed.\n\nThe `join()` calls are equally important. They make the main thread wait until all worker threads have completed before printing the final count. Without joins, you might print the count while threads are still incrementing.\n\n---\n\n# Performance Considerations\n\nMutexes are not free. Every `lock()` and `unlock()` adds overhead, and that overhead can explode when many threads compete for the same lock. \n\nThe goal is not to avoid locks at all costs. The goal is to understand when locking is “cheap enough” and when contention turns it into a bottleneck.\n\n### Overhead\n\nA mutex is fast when **no one is competing**. In that case, lock acquisition is often just a few atomic instructions.\n\nOnce there is contention, things change. The runtime may need to park threads, manage wait queues, and involve the OS scheduler.\n\n\n| Operation | Typical Cost | Notes |\n|-----------|--------------|-------|\n| Uncontended lock/unlock | 10-100 ns | Fast atomic operations |\n| Contended lock (context switch) | 1-10 μs | OS scheduler involved |\n| Contended lock (many waiters) | 10-100 μs | Queue management, fairness |\n\n\nTreat these numbers as ballpark. The exact values vary by OS, CPU, JVM/runtime, and contention pattern. The trend is what matters: contention can be 100–1000× more expensive than an uncontended lock.\n\n### Lock Contention\n\nContention occurs when multiple threads compete for the same lock. High contention causes:\n\n- Threads spend more time waiting than working\n- Excessive context switching\n- Poor CPU utilization\n- Serialized execution (defeating the purpose of multithreading)\n\nConsider a web server with 100 threads, all accessing a shared cache protected by a single mutex. If each request needs the cache for 1ms, and requests arrive faster than 1 per millisecond, threads start queueing. With high load, 99 threads might be blocked waiting while 1 thread works. \n\nYour system may have many cores, but this hotspot makes it behave like a single-core pipeline at the lock boundary.\n\nThis is why high-throughput systems often use more sophisticated approaches: sharded locks, lock-free data structures, or thread-local caching.\n\n### Optimization Strategies\n\n**1. Minimize critical section size:** Only lock what's necessary\n\n\n```java\n// BAD\nsynchronized (lock) {\n data = computeExpensiveValue(); // Don't hold lock during computation\n cache.put(key, data);\n}\n\n// GOOD\nObject data = computeExpensiveValue(); // Compute outside lock\nsynchronized (lock) {\n cache.put(key, data); // Only lock the mutation\n}\n```\n\n```python\n# BAD\nwith self.lock:\n data = compute_expensive_value() # Don't hold lock during computation\n self.cache[key] = data\n\n# GOOD\ndata = compute_expensive_value() # Compute outside lock\nwith self.lock:\n self.cache[key] = data # Only lock the mutation\n```\n\n```cpp\n// BAD\n{\n std::lock_guard lock(mtx_);\n data = computeExpensiveValue(); // Don't hold lock during computation\n cache_[key] = data;\n}\n\n// GOOD\nauto data = computeExpensiveValue(); // Compute outside lock\n{\n std::lock_guard lock(mtx_);\n cache_[key] = data; // Only lock the mutation\n}\n```\n\n```csharp\n// BAD\nlock (lockObj)\n{\n data = ComputeExpensiveValue(); // Don't hold lock during computation\n cache[key] = data;\n}\n\n// GOOD\nvar data = ComputeExpensiveValue(); // Compute outside lock\nlock (lockObj)\n{\n cache[key] = data; // Only lock the mutation\n}\n```\n\n```go\n// BAD\nfunc (c *Cache) Store(key string) {\n c.mu.Lock()\n defer c.mu.Unlock()\n data := computeExpensiveValue() // Don't hold lock during computation\n c.cache[key] = data\n}\n\n// GOOD\nfunc (c *Cache) Store(key string) {\n data := computeExpensiveValue() // Compute outside lock\n c.mu.Lock()\n defer c.mu.Unlock()\n c.cache[key] = data // Only lock the mutation\n}\n```\n\n\nThis single change often gives the biggest win because it reduces lock hold time, which reduces contention.\n\n**2. Use finer-grained locks:** If two operations do not touch the same data, they should not fight over the same lock.\n\n\n```java\n// BAD - one lock for everything\nclass UserService {\n private final Lock lock = new ReentrantLock();\n private Map users;\n private Map sessions;\n // All operations compete for same lock\n}\n\n// GOOD - separate locks for independent data\nclass UserService {\n private final Lock usersLock = new ReentrantLock();\n private final Lock sessionsLock = new ReentrantLock();\n private Map users;\n private Map sessions;\n // User operations don't block session operations\n}\n```\n\n```python\n# BAD - one lock for everything\nclass UserService:\n def __init__(self):\n self.lock = threading.Lock()\n self.users = {}\n self.sessions = {}\n # All operations compete for same lock\n\n# GOOD - separate locks for independent data\nclass UserService:\n def __init__(self):\n self.users_lock = threading.Lock()\n self.sessions_lock = threading.Lock()\n self.users = {}\n self.sessions = {}\n # User operations don't block session operations\n```\n\n```cpp\n// BAD - one lock for everything\nclass UserService {\n std::mutex mtx_;\n std::unordered_map users_;\n std::unordered_map sessions_;\n // All operations compete for same lock\n};\n\n// GOOD - separate locks for independent data\nclass UserService {\n std::mutex users_mtx_;\n std::mutex sessions_mtx_;\n std::unordered_map users_;\n std::unordered_map sessions_;\n // User operations don't block session operations\n};\n```\n\n```csharp\n// BAD - one lock for everything\npublic class UserService\n{\n private readonly object lockObj = new object();\n private Dictionary users = new Dictionary();\n private Dictionary sessions = new Dictionary();\n // All operations compete for same lock\n}\n\n// GOOD - separate locks for independent data\npublic class UserService\n{\n private readonly object usersLock = new object();\n private readonly object sessionsLock = new object();\n private Dictionary users = new Dictionary();\n private Dictionary sessions = new Dictionary();\n // User operations don't block session operations\n}\n```\n\n```go\n// BAD - one lock for everything\ntype UserService struct {\n mu sync.Mutex\n users map[string]*User\n sessions map[string]*Session\n // All operations compete for same lock\n}\n\n// GOOD - separate locks for independent data\ntype UserService struct {\n usersMu sync.Mutex\n sessionsMu sync.Mutex\n users map[string]*User\n sessions map[string]*Session\n // User operations don't block session operations\n}\n```\n\n\nThis reduces unnecessary blocking and improves throughput, at the cost of more complexity. Once you have multiple locks, you must also think about lock ordering to avoid deadlocks.\n\n**3. Prefer atomics for simple counters:** For small, well-defined operations like incrementing a counter, atomic types often beat a mutex because they avoid blocking entirely.\n\n\n```java\n// Lock-based\nprivate int counter;\nprivate final Lock lock = new ReentrantLock();\n\npublic void increment() {\n lock.lock();\n try { counter++; } finally { lock.unlock(); }\n}\n\n// Lock-free (often faster)\nprivate final AtomicInteger counter = new AtomicInteger();\n\npublic void increment() {\n counter.incrementAndGet();\n}\n```\n\n```python\n# Lock-based\nclass Counter:\n def __init__(self):\n self.counter = 0\n self.lock = threading.Lock()\n\n def increment(self):\n with self.lock:\n self.counter += 1\n\n# Note: Python doesn't have built-in atomic integers, but for\n# simple counters, consider using multiprocessing.Value or\n# third-party libraries like atomics\nfrom multiprocessing import Value\n\nclass AtomicCounter:\n def __init__(self):\n self.counter = Value('i', 0) # 'i' = signed int\n\n def increment(self):\n with self.counter.get_lock():\n self.counter.value += 1\n```\n\n```cpp\n// Lock-based\nclass Counter {\n int counter_ = 0;\n std::mutex mtx_;\n\npublic:\n void increment() {\n std::lock_guard lock(mtx_);\n counter_++;\n }\n};\n\n// Lock-free (often faster)\nclass AtomicCounter {\n std::atomic counter_{0};\n\npublic:\n void increment() {\n counter_.fetch_add(1, std::memory_order_relaxed);\n }\n};\n```\n\n```csharp\n// Lock-based\npublic class Counter\n{\n private int counter;\n private readonly object lockObj = new object();\n\n public void Increment()\n {\n lock (lockObj)\n {\n counter++;\n }\n }\n}\n\n// Lock-free (often faster)\npublic class AtomicCounter\n{\n private int counter;\n\n public void Increment()\n {\n Interlocked.Increment(ref counter);\n }\n\n public int GetValue()\n {\n return Interlocked.CompareExchange(ref counter, 0, 0); // Atomic read\n }\n}\n```\n\n```go\n// Lock-based\ntype Counter struct {\n mu sync.Mutex\n count int64\n}\n\nfunc (c *Counter) Increment() {\n c.mu.Lock()\n defer c.mu.Unlock()\n c.count++\n}\n\n// Lock-free (often faster)\ntype AtomicCounter struct {\n count int64\n}\n\nfunc (c *AtomicCounter) Increment() {\n atomic.AddInt64(&c.count, 1)\n}\n\nfunc (c *AtomicCounter) GetValue() int64 {\n return atomic.LoadInt64(&c.count)\n}\n```\n\n\nAtomics are not “free” either. They still use atomic instructions and memory ordering rules. But for simple patterns, they can be a clean upgrade.\n\n**4. Use read-write locks when reads dominate:** If your workload is “many readers, few writers,” a `ReadWriteLock` can improve concurrency by letting readers proceed in parallel.\n\n\n```java\nprivate final ReadWriteLock rwLock = new ReentrantReadWriteLock();\n\npublic Object read(String key) {\n rwLock.readLock().lock(); // Multiple readers allowed\n try {\n return cache.get(key);\n } finally {\n rwLock.readLock().unlock();\n }\n}\n\npublic void write(String key, Object value) {\n rwLock.writeLock().lock(); // Exclusive access\n try {\n cache.put(key, value);\n } finally {\n rwLock.writeLock().unlock();\n }\n}\n```\n\n```python\nimport threading\n\nclass Cache:\n def __init__(self):\n self.cache = {}\n self.rw_lock = threading.RLock() # Python doesn't have built-in RWLock\n # For true read-write lock, use third-party: readerwriterlock package\n\n # With readerwriterlock package:\n # from readerwriterlock import rwlock\n # self.rw_lock = rwlock.RWLockFair()\n\n def read(self, key):\n # with self.rw_lock.gen_rlock(): # Multiple readers allowed\n with self.rw_lock:\n return self.cache.get(key)\n\n def write(self, key, value):\n # with self.rw_lock.gen_wlock(): # Exclusive access\n with self.rw_lock:\n self.cache[key] = value\n```\n\n```cpp\n#include \n#include \n\nclass Cache {\n std::unordered_map cache_;\n mutable std::shared_mutex rw_mtx_;\n\npublic:\n std::string read(const std::string& key) const {\n std::shared_lock lock(rw_mtx_); // Multiple readers\n auto it = cache_.find(key);\n return (it != cache_.end()) ? it->second : \"\";\n }\n\n void write(const std::string& key, const std::string& value) {\n std::unique_lock lock(rw_mtx_); // Exclusive access\n cache_[key] = value;\n }\n};\n```\n\n```csharp\nusing System.Collections.Generic;\nusing System.Threading;\n\npublic class Cache\n{\n private readonly Dictionary cache = new Dictionary();\n private readonly ReaderWriterLockSlim rwLock = new ReaderWriterLockSlim();\n\n public string Read(string key)\n {\n rwLock.EnterReadLock(); // Multiple readers allowed\n try\n {\n return cache.TryGetValue(key, out var value) ? value : null;\n }\n finally\n {\n rwLock.ExitReadLock();\n }\n }\n\n public void Write(string key, string value)\n {\n rwLock.EnterWriteLock(); // Exclusive access\n try\n {\n cache[key] = value;\n }\n finally\n {\n rwLock.ExitWriteLock();\n }\n }\n}\n```\n\n```go\nimport \"sync\"\n\ntype Cache struct {\n mu sync.RWMutex\n cache map[string]string\n}\n\nfunc NewCache() *Cache {\n return &Cache{cache: make(map[string]string)}\n}\n\nfunc (c *Cache) Read(key string) (string, bool) {\n c.mu.RLock() // Multiple readers allowed\n defer c.mu.RUnlock()\n val, ok := c.cache[key]\n return val, ok\n}\n\nfunc (c *Cache) Write(key, value string) {\n c.mu.Lock() // Exclusive access\n defer c.mu.Unlock()\n c.cache[key] = value\n}\n```\n\n\nThis helps only when:\n\n- reads greatly outnumber writes, and\n- reads are not extremely short (otherwise lock overhead can dominate), and\n- writers are not frequent enough to starve readers or vice versa.\n\n---\n\n# Quiz","pageType":"concurrency-interview"}

Get Premium