46:"/_next/static/chunks/33yus346z0l_n.js" 47:"/_next/static/chunks/1r8ezocsukqp8.js" 48:"/_next/static/chunks/0iv56yrji_20j.js" 49:"/_next/static/chunks/0wa9m1-tphf9u.js" 4a:"/_next/static/chunks/08cuqqn_f60pp.js" 4b:"/_next/static/chunks/3zdsl3f9b0--r.js" 4c:"/_next/static/chunks/2j22cxchii_xx.js" 4d:"/_next/static/chunks/3bgoyiso1rhn7.js" 4e:"/_next/static/chunks/01a-3hvnqu8wl.js" 4f:"/_next/static/chunks/3m1xjj5kw5fie.js" 50:"/_next/static/chunks/0om3fkgfnicab.js" 51:"/_next/static/chunks/0gafyzg9j9yqj.js" 52:"/_next/static/chunks/20w4eaqlekefm.js" 53:"/_next/static/chunks/449--h5z1s6nq.js" 54:"/_next/static/chunks/3k2gyg36fnag_.js" 55:"/_next/static/chunks/18ggtgz2yf759.js" 56:"/_next/static/chunks/0hlb44ca7-4a2.js" 57:"/_next/static/chunks/253gnmj0-cj17.js" 58:"/_next/static/chunks/09nq57stwzkgf.js" 59:"/_next/static/chunks/082jo-0ajazgr.js" 5a:"/_next/static/chunks/2ozcrjb_hh74t.js" 5b:"/_next/static/chunks/05i8en-x14ibi.js" 5c:"/_next/static/chunks/32izpn90gvm22.js" 5d:"/_next/static/chunks/0jbzid2v9xv3h.js" 5e:"/_next/static/chunks/0i3-eynrkvqi7.js" 5f:"/_next/static/chunks/1tn-0fivsxsv1.js" 60:"/_next/static/chunks/34h36hyf_ggow.js" 61:"/_next/static/chunks/20329i6m_04t6.js" 62:"/_next/static/chunks/161uxd62cjny2.js" 63:"/_next/static/chunks/2k8pepwc4pxns.js" 64:I[593304,["$2b","$2c","$2d","$2e","$2f","$30","$46","$47","$48","$49","$4a","$4b","$4c","$4d","$4e","$4f","$50","$51","$52","$53","$54","$55","$56","$57","$58","$59","$5a","$5b","$5c","$5d","$5e","$5f","$60","$61","$62","$63"],"OwnedHydration"] 65:T48e,// Conceptual mutex structure class Mutex { private boolean locked = false; private Thread owner = null; private Queue waitQueue = new Queue<>(); // Acquire the lock (blocking) void lock() { while (true) { // Atomic check-and-set operation (hardware supported) if (atomicCompareAndSwap(locked, false, true)) { // Successfully acquired owner = currentThread(); memoryBarrier(); // Ensure visibility return; } // Failed to acquire - add to wait queue and sleep waitQueue.enqueue(currentThread()); parkThread(currentThread()); // Yield CPU } } // Release the lock void unlock() { if (owner != currentThread()) { throw IllegalMonitorStateException("Not lock owner"); } memoryBarrier(); // Flush all writes owner = null; locked = false; // Wake up a waiting thread if (!waitQueue.isEmpty()) { Thread next = waitQueue.dequeue(); unparkThread(next); } } }66:T4f8,import java.util.concurrent.locks.ReentrantLock; class ReentrantLockExample { private final ReentrantLock lock = new ReentrantLock(); private int balance = 1000; public void withdraw(int amount) { lock.lock(); try { if (balance >= amount) { balance -= amount; } } finally { lock.unlock(); } } public void transfer(int amount, ReentrantLockExample target) { lock.lock(); // First acquisition try { // Can safely call withdraw which also locks withdraw(amount); // Second acquisition (same thread) - OK! target.deposit(amount); } finally { lock.unlock(); // Decrements hold count } } public void deposit(int amount) { lock.lock(); try { balance += amount; } finally { lock.unlock(); } } // Check lock status (useful for debugging) public void debugInfo() { System.out.println("Hold count: " + lock.getHoldCount()); System.out.println("Is held by current thread: " + lock.isHeldByCurrentThread()); System.out.println("Queue length: " + lock.getQueueLength()); } }67:T474,import threading class ReentrantLockExample: def __init__(self): # RLock is reentrant (same thread can acquire multiple times) self.lock = threading.RLock() self.balance = 1000 def withdraw(self, amount): with self.lock: if self.balance >= amount: self.balance -= amount return True return False def transfer(self, amount, target): with self.lock: # First acquisition # This nested call is safe with RLock if self.withdraw(amount): # Second acquisition - OK! target.deposit(amount) def deposit(self, amount): with self.lock: self.balance += amount # Demonstrating reentrant behavior def nested_calls(self): with self.lock: print("First level") with self.lock: # Same thread - allowed print("Second level") with self.lock: # Same thread - allowed print("Third level") # Second-level lock releases # First-level lock releases68:T430,#include class ReentrantLockExample { private: std::recursive_mutex mtx; // Reentrant mutex int balance = 1000; public: void withdraw(int amount) { std::lock_guard lock(mtx); if (balance >= amount) { balance -= amount; } } void transfer(int amount, ReentrantLockExample& target) { std::lock_guard lock(mtx); // Safe: same thread can re-acquire withdraw(amount); target.deposit(amount); } void deposit(int amount) { std::lock_guard lock(mtx); balance += amount; } // Nested locking demonstration void nestedOperations() { std::lock_guard lock1(mtx); // First level { std::lock_guard lock2(mtx); // Second level - same thread, OK // Operations here... } // lock2 releases (decrements count) } // lock1 releases (count = 0, actual unlock) };69:T60f,import java.util.concurrent.locks.ReentrantReadWriteLock; import java.util.Map; import java.util.HashMap; class ThreadSafeCache { private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock(); private final Map cache = new HashMap<>(); // Multiple threads can read simultaneously public V get(K key) { rwLock.readLock().lock(); try { return cache.get(key); } finally { rwLock.readLock().unlock(); } } // Writers need exclusive access public void put(K key, V value) { rwLock.writeLock().lock(); try { cache.put(key, value); } finally { rwLock.writeLock().unlock(); } } // Upgrade pattern: check then write public V computeIfAbsent(K key, Supplier supplier) { // First, try read lock rwLock.readLock().lock(); try { V value = cache.get(key); if (value != null) { return value; } } finally { rwLock.readLock().unlock(); } // Need write lock for insertion rwLock.writeLock().lock(); try { // Double-check after acquiring write lock V value = cache.get(key); if (value == null) { value = supplier.get(); cache.put(key, value); } return value; } finally { rwLock.writeLock().unlock(); } } }6a:T5dc,import threading from typing import Dict, TypeVar, Callable, Optional K = TypeVar('K') V = TypeVar('V') class ThreadSafeCache: def __init__(self): self.rwlock = threading.RWLock() # Python 3.13+ self.cache: Dict = {} def get(self, key): with self.rwlock.reader(): return self.cache.get(key) def put(self, key, value): with self.rwlock.writer(): self.cache[key] = value def compute_if_absent(self, key, supplier: Callable): # Read phase with self.rwlock.reader(): if key in self.cache: return self.cache[key] # Write phase (double-check pattern) with self.rwlock.writer(): if key not in self.cache: self.cache[key] = supplier() return self.cache[key] # For older Python, use this implementation class RWLock: def __init__(self): self._read_ready = threading.Condition(threading.Lock()) self._readers = 0 def acquire_read(self): with self._read_ready: self._readers += 1 def release_read(self): with self._read_ready: self._readers -= 1 if self._readers == 0: self._read_ready.notify_all() def acquire_write(self): self._read_ready.acquire() while self._readers > 0: self._read_ready.wait() def release_write(self): self._read_ready.release()6b:T549,#include // C++17 #include #include template class ThreadSafeCache { private: mutable std::shared_mutex rwMutex; std::unordered_map cache; public: // Multiple readers allowed std::optional get(const K& key) const { std::shared_lock lock(rwMutex); auto it = cache.find(key); if (it != cache.end()) { return it->second; } return std::nullopt; } // Exclusive write access void put(const K& key, const V& value) { std::unique_lock lock(rwMutex); cache[key] = value; } // Double-checked locking pattern V computeIfAbsent(const K& key, std::function supplier) { // First try with shared lock { std::shared_lock lock(rwMutex); auto it = cache.find(key); if (it != cache.end()) { return it->second; } } // Upgrade to exclusive lock std::unique_lock lock(rwMutex); // Double-check after acquiring exclusive lock auto it = cache.find(key); if (it == cache.end()) { cache[key] = supplier(); } return cache[key]; } };6c:T43b,// DEADLOCK SCENARIO class BankAccount { private final Object lock = new Object(); private int balance; // Thread A: transfer(accountX, accountY, 100) // Thread B: transfer(accountY, accountX, 50) // If they interleave, both wait forever void transferDeadlock(BankAccount from, BankAccount to, int amt) { synchronized(from.lock) { // A locks X, B locks Y // Context switch! synchronized(to.lock) { // A waits for Y, B waits for X from.balance -= amt; // Neither reaches here to.balance += amt; } } } // FIX: Always lock in consistent order (by account ID) void transferSafe(BankAccount from, BankAccount to, int amt) { BankAccount first = from.hashCode() < to.hashCode() ? from : to; BankAccount second = first == from ? to : from; synchronized(first.lock) { synchronized(second.lock) { from.balance -= amt; to.balance += amt; } } } }45:["$","$L64",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792317979095,"state":{"data":{"json":{"id":"seed_92960a7074a8134c2af152275a8f8a6f","slug":"synchronization-primitives","category":"System Design (LLD)","topic":"Synchronization Primitives","title":"Synchronization Primitives: Coordinating Concurrent Access","description":"Master the essential synchronization mechanisms—mutexes, semaphores, and monitors—that enable safe coordination between concurrent threads. Learn when and how to apply each primitive, understand their performance trade-offs, and develop the judgment to select the right tool for any concurrency challenge.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_372ef74a61ca7ce0ae866fe4b6303fbb","title":"Mutex and Locks: Ensuring Exclusive Access","order":0,"content":[{"id":"opening-hook","title":"The Gatekeeper of Shared Resources","content":[{"data":{"content":"Imagine a narrow bridge that can only support one vehicle at a time. Without traffic control, cars approaching from both directions would collide mid-span, causing catastrophic failure. The solution is obvious: install a traffic light that grants exclusive passage to one direction at a time.\n\n**Mutexes (Mutual Exclusion locks) are the traffic lights of concurrent programming.** They ensure that when multiple threads need to access a shared resource—a bank account balance, a file, a database connection—only one thread can do so at any given moment. This seemingly simple concept is the foundation upon which all thread-safe systems are built.\n\nBut like many foundational concepts, the devil lies in the details. This page explores mutexes and their lock variants with the depth required to use them correctly in production systems."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By completing this page, you will understand the theoretical foundations of mutual exclusion, the anatomy of mutex implementations, different lock types (reentrant, read-write, spin), their performance characteristics, correct usage patterns, and common pitfalls that lead to bugs in production systems.","variant":"info"},"type":"callout"}]},{"id":"problem-mutexes-solve","title":"The Problem Mutexes Solve","content":[{"data":{"content":"Before diving into solutions, we must viscerally understand the problem. The core issue is **race conditions**—scenarios where the behavior of a program depends on the relative timing of events, particularly the order in which threads execute.\n\nConsider a simple counter increment operation:\n\n```\ncounter = counter + 1\n```\n\nThis single line of code appears atomic, but at the CPU level, it involves three distinct operations:"},"type":"text"},{"data":{"type":"ordered","items":["**READ**: Load the current value of `counter` from memory into a CPU register","**MODIFY**: Add 1 to the register value","**WRITE**: Store the new value from the register back to memory"],"title":{"icon":"Zap","text":"The Three-Step Nature of Increment","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"When two threads execute this operation simultaneously on an initial counter value of 0, here's what can go wrong:"},"type":"text"},{"data":{"rows":[["Initial","—","—","?","?","0"],["1","READ counter","—","0","?","0"],["2","—","READ counter","0","0","0"],["3","ADD 1","—","1","0","0"],["4","—","ADD 1","1","1","0"],["5","WRITE counter","—","1","1","1"],["6","—","WRITE counter","1","1","1"]],"caption":"Race Condition: Lost Update Problem","headers":["Step","Thread A","Thread B","Register A","Register B","Memory"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Lost Update","content":"Both threads incremented the counter, but the final value is 1 instead of 2. Thread B's update was 'lost' because it read the value before Thread A's write completed. In a banking system, this is literal money disappearing. In inventory systems, this means overselling products. In metrics systems, this means incorrect analytics driving wrong business decisions.","variant":"error"},"type":"callout"},{"data":{"content":"This problem is particularly insidious because:\n\n1. **It's non-deterministic**: The bug might manifest once in a million executions\n2. **It's hard to reproduce**: Adding logging or debugging often changes timing enough to mask the issue\n3. **It scales with concurrency**: The more threads, the higher the probability of corruption\n4. **It's silent**: No exceptions are thrown; the system just produces wrong results\n\n**Mutexes solve this by ensuring atomicity at a higher level than individual CPU instructions.** They create protected regions called **critical sections** where only one thread can execute at a time."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"anatomy-of-mutex","title":"Anatomy of a Mutex","content":[{"data":{"content":"A mutex is conceptually simple: it has two states (locked/unlocked) and two operations (acquire/release). But understanding *how* these operations work at a lower level is essential for using mutexes effectively.\n\n**The Mutex Contract:**"},"type":"text"},{"data":{"items":["**Mutual Exclusion**: At most one thread can hold the lock at any time","**Progress**: If no thread holds the lock and threads are waiting, one will eventually acquire it","**Bounded Waiting**: There's a limit on how long any thread can be starved (in fair implementations)","**Memory Visibility**: Actions before releasing the lock are visible to the thread that next acquires it"],"title":{"icon":"CheckCircle","text":"Mutex Guarantees","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"The last guarantee—**memory visibility**—is often overlooked but critically important. Modern CPUs reorder instructions and cache values aggressively. A mutex release includes a **memory barrier** (or fence) that ensures all writes by the releasing thread are visible to subsequent lock acquirers.\n\n**Pseudocode for Mutex Operations:**"},"type":"text"},{"data":{"code":"$65","fileName":"mutex-conceptual.pseudo"},"type":"code"},{"data":{"content":"**Critical Implementation Details:**\n\n**1. Atomic Compare-And-Swap (CAS):**\nThe `atomicCompareAndSwap` operation is the magic that makes everything work. It atomically checks if a variable has an expected value and, only if so, updates it to a new value. This is a single CPU instruction (`CMPXCHG` on x86, `LDREX/STREX` on ARM) that cannot be interrupted.\n\n**2. Wait Queue Management:**\nWhen a thread fails to acquire the lock, it must either spin (busy-wait) or sleep. Sleeping requires OS kernel involvement to manage the wait queue and wake threads. This is expensive but necessary for long waits.\n\n**3. Memory Barriers:**\nThe barriers ensure the **happens-before** relationship: everything that happened before a thread released the lock is visible to the thread that subsequently acquires it. Without this, threads might see stale cached values."},"type":"text"},{"data":{"icon":"Info","title":"Hardware Foundation","content":"Mutexes ultimately rely on hardware atomic instructions. Without CPU support for atomic operations, implementing correct synchronization would require disabling interrupts—possible only in kernel mode. User-space locks leverage kernel assistance (futexes on Linux, Critical Sections on Windows) to efficiently coordinate without burning CPU cycles.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"lock-types","title":"Lock Types and Variations","content":[{"data":{"content":"Not all locks are created equal. Different concurrency scenarios call for different lock behaviors. Understanding the variations helps you select the right tool for each situation."},"type":"text"},{"data":{"tabs":[{"id":"basic-mutex","label":"Basic Mutex","content":[{"data":{"content":"**The Standard Mutex (Non-Reentrant)**\n\nThe simplest form of mutex allows exactly one thread to hold it. If the same thread attempts to acquire a lock it already holds, it **deadlocks** against itself.\n\n**Characteristics:**\n- Single owner at a time\n- Non-reentrant (self-deadlock possible)\n- Lowest overhead\n- Use when: You can guarantee no nested locking scenarios"},"type":"text"},{"data":{"languages":[{"code":"// Java provides ReentrantLock, but you can use synchronized \n// (which IS reentrant) or a Semaphore(1) for non-reentrant behavior\n\nimport java.util.concurrent.Semaphore;\n\nclass NonReentrantLockExample {\n // Semaphore with 1 permit acts as non-reentrant mutex\n private final Semaphore mutex = new Semaphore(1);\n private int sharedCounter = 0;\n \n public void increment() throws InterruptedException {\n mutex.acquire(); // Block until permit available\n try {\n sharedCounter++; // Protected critical section\n } finally {\n mutex.release(); // Always release in finally\n }\n }\n \n // WARNING: This would deadlock!\n public void nestedOperation() throws InterruptedException {\n mutex.acquire();\n try {\n // This will block forever - we already hold the permit\n // increment(); // DEADLOCK!\n } finally {\n mutex.release();\n }\n }\n}","label":"Java","value":"java"},{"code":"import threading\n\n# Python's Lock is non-reentrant\n# Attempting to acquire twice from same thread = deadlock\n\nclass NonReentrantExample:\n def __init__(self):\n self.mutex = threading.Lock() # Non-reentrant\n self.shared_counter = 0\n \n def increment(self):\n self.mutex.acquire()\n try:\n self.shared_counter += 1\n finally:\n self.mutex.release()\n \n # Pythonic way using context manager\n def increment_pythonic(self):\n with self.mutex: # Auto acquire/release\n self.shared_counter += 1\n \n # This would deadlock!\n def nested_call(self):\n with self.mutex:\n # self.increment() # DEADLOCK - same thread, non-reentrant\n pass","label":"Python","value":"python"},{"code":"#include \n\nclass NonReentrantExample {\nprivate:\n std::mutex mtx; // Non-reentrant by default\n int sharedCounter = 0;\n\npublic:\n void increment() {\n std::lock_guard lock(mtx); // RAII pattern\n sharedCounter++; // Protected\n } // Auto-unlock on scope exit\n \n // Alternative: manual lock/unlock\n void manualIncrement() {\n mtx.lock();\n try {\n sharedCounter++;\n } catch (...) {\n mtx.unlock(); // Must unlock on exception\n throw;\n }\n mtx.unlock();\n }\n \n // WARNING: Would deadlock if called while holding lock\n void nestedOperation() {\n std::lock_guard lock(mtx);\n // increment(); // DEADLOCK!\n }\n};","label":"C++","value":"cpp"}]},"type":"code"}],"titleIcon":"Target"},{"id":"reentrant-lock","label":"Reentrant Lock","content":[{"data":{"content":"**Reentrant Lock (Recursive Mutex)**\n\nA reentrant lock can be acquired multiple times by the **same thread** without blocking. It maintains an acquisition count and only fully releases when the count reaches zero.\n\n**Characteristics:**\n- Same thread can acquire multiple times\n- Maintains hold count\n- Slightly higher overhead than basic mutex\n- Use when: Methods may call other methods that require the same lock"},"type":"text"},{"data":{"languages":[{"code":"$66","label":"Java","value":"java"},{"code":"$67","label":"Python","value":"python"},{"code":"$68","label":"C++","value":"cpp"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"Reentrant Lock Caveat","content":"While reentrant locks prevent self-deadlock, they can mask design problems. If you find yourself relying heavily on reentrancy, consider whether your code structure could be improved. Excessive nesting often indicates unclear responsibility boundaries.","variant":"warning"},"type":"callout"}],"titleIcon":"Zap"},{"id":"spin-lock","label":"Spin Lock","content":[{"data":{"content":"**Spin Lock (Busy-Wait Lock)**\n\nA spin lock repeatedly checks (\"spins\") in a tight loop until the lock becomes available, rather than yielding the CPU. This avoids the overhead of context switching but wastes CPU cycles.\n\n**Characteristics:**\n- No context switch overhead\n- Wastes CPU while waiting\n- Best for very short critical sections\n- Use when: Lock hold time < context switch time (~1-10μs)"},"type":"text"},{"data":{"languages":[{"code":"import java.util.concurrent.atomic.AtomicBoolean;\n\nclass SpinLock {\n private final AtomicBoolean locked = new AtomicBoolean(false);\n \n public void lock() {\n // Spin until we successfully set locked to true\n while (!locked.compareAndSet(false, true)) {\n // Optional: yield hint for hyperthreading\n Thread.onSpinWait(); // Java 9+ intrinsic\n }\n }\n \n public void unlock() {\n locked.set(false);\n }\n}\n\n// Ticket spin lock (fair ordering)\nclass TicketSpinLock {\n private final AtomicInteger ticketCounter = new AtomicInteger(0);\n private final AtomicInteger servingCounter = new AtomicInteger(0);\n \n public void lock() {\n int myTicket = ticketCounter.getAndIncrement();\n while (servingCounter.get() != myTicket) {\n Thread.onSpinWait(); // Wait for our turn\n }\n }\n \n public void unlock() {\n servingCounter.incrementAndGet(); // Serve next ticket\n }\n}","label":"Java","value":"java"},{"code":"#include \n\nclass SpinLock {\nprivate:\n std::atomic_flag flag = ATOMIC_FLAG_INIT;\n\npublic:\n void lock() {\n // test_and_set returns previous value\n // Keep spinning while it was already set (locked)\n while (flag.test_and_set(std::memory_order_acquire)) {\n // Optional: pause instruction for power efficiency\n #if defined(__x86_64__) || defined(_M_X64)\n __builtin_ia32_pause(); // x86 PAUSE instruction\n #endif\n }\n }\n \n void unlock() {\n flag.clear(std::memory_order_release);\n }\n};\n\n// RAII wrapper for safe usage\nclass SpinLockGuard {\nprivate:\n SpinLock& lock_;\npublic:\n explicit SpinLockGuard(SpinLock& lock) : lock_(lock) {\n lock_.lock();\n }\n ~SpinLockGuard() {\n lock_.unlock();\n }\n};","label":"C++","value":"cpp"}]},"type":"code"},{"data":{"icon":"AlertCircle","title":"Spin Lock on Single-Core","content":"Never use spin locks on single-core systems! The thread holding the lock cannot release it while another thread is spinning—resulting in a 100% CPU usage deadlock until the OS preempts the spinning thread. Spin locks only make sense when threads can truly run in parallel on different cores.","variant":"warning"},"type":"callout"}],"titleIcon":"Sparkles"},{"id":"read-write-lock","label":"Read-Write Lock","content":[{"data":{"content":"**Read-Write Lock (Shared-Exclusive Lock)**\n\nRead-write locks recognize that many concurrent reads are safe—it's only writes that require exclusivity. Multiple readers can hold the lock simultaneously, but writers require exclusive access.\n\n**Characteristics:**\n- Multiple concurrent readers allowed\n- Writers require exclusive access\n- Higher overhead than simple mutex\n- Use when: Read-heavy workloads (80%+ reads)"},"type":"text"},{"data":{"languages":[{"code":"$69","label":"Java","value":"java"},{"code":"$6a","label":"Python","value":"python"},{"code":"$6b","label":"C++","value":"cpp"}]},"type":"code"}],"titleIcon":"BookOpen"}]},"type":"tabs"}],"titleType":"number","titleNumber":3},{"id":"lock-usage-patterns","title":"Lock Usage Patterns and Best Practices","content":[{"data":{"content":"Acquiring locks correctly is only half the battle. How you structure code around locks determines whether your concurrent programs are robust or riddled with subtle bugs."},"type":"text"},{"data":{"items":["**Always use try-finally (or RAII)**: The lock MUST be released even if an exception occurs. Forgetting to unlock leads to permanent deadlock.","**Keep critical sections small**: Hold locks for the minimum time necessary. Do I/O, computation, and allocations outside the lock when possible.","**Don't perform blocking I/O while holding locks**: Network calls, file operations, and database queries can take seconds—blocking all other threads.","**Acquire locks in consistent order**: If you need multiple locks, always acquire them in the same order everywhere to prevent deadlock.","**Prefer lock-free alternatives when available**: Atomic operations, concurrent collections, and immutable data often outperform explicit locking."],"title":{"icon":"CheckCircle","text":"Essential Lock Patterns","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"left":[{"data":{"items":["Lock acquired before I/O","Network call holds the lock","All threads blocked during fetch","Throughput: ~10 req/sec"],"title":{"icon":"XCircle","text":"Anti-Pattern: Wide Critical Section","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"code":"// BAD: I/O inside critical section\nvoid updateFromServer() {\n lock.acquire();\n try {\n // Network call takes 100ms!\n data = httpClient.fetch(url);\n cache.put(key, data);\n } finally {\n lock.unlock();\n }\n}"},"type":"code"}],"right":[{"data":{"items":["I/O performed outside lock","Only cache update is locked","Threads can parallelize I/O","Throughput: ~1000 req/sec"],"title":{"icon":"CheckCircle","text":"Correct: Minimal Critical Section","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"code":"// GOOD: I/O outside critical section\nvoid updateFromServer() {\n // Network call without lock\n var data = httpClient.fetch(url);\n \n lock.acquire();\n try {\n cache.put(key, data); // Only this\n } finally {\n lock.unlock();\n }\n}"},"type":"code"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"The 100x Throughput Difference","content":"Moving a 100ms network call outside the lock transforms a system from 10 operations/second (serialized) to potentially 1000+ operations/second (parallel I/O with minimal lock contention). Critical section minimization is one of the highest-leverage performance optimizations in concurrent systems.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"common-pitfalls","title":"Common Pitfalls and How to Avoid Them","content":[{"data":{"content":"Even experienced developers make locking mistakes. Understanding common pitfalls helps you write more robust concurrent code from the start."},"type":"text"},{"data":{"slides":[{"icon":"AlertCircle","extra":"Solution: Return defensive copies, or use immutable wrappers. Never expose internal state directly.","title":"Pitfall #1: Lock Escape","description":"Leaking a reference to protected data allows it to be accessed without the lock. Even if you synchronize access to a collection, returning an iterator or inner reference breaks safety."},{"icon":"AlertCircle","extra":"Solution: Use atomic operations like computeIfPresent, or hold the lock across check-then-act.","title":"Pitfall #2: Check-Then-Act Race","description":"Checking a condition and acting on it non-atomically: 'if (map.containsKey(k)) { map.remove(k); }'. Another thread might remove the key between check and act."},{"icon":"AlertCircle","extra":"Solution: Make lock instances final. Document which lock protects which data. Use code review.","title":"Pitfall #3: Wrong Lock Instance","description":"Using a different lock object than intended. Creating a local lock variable instead of using the shared instance. Using 'this' when a static lock was needed."},{"icon":"AlertCircle","extra":"Solution: Use fine-grained locks—one per logical resource. Consider striped locks for collections.","title":"Pitfall #4: Coarse Lock Granularity","description":"Using a single lock for unrelated data. All operations serialize even when they don't conflict. This creates artificial bottlenecks under high concurrency."},{"icon":"AlertCircle","extra":"Solution: Always acquire locks in the same global order. Use tryLock with timeout to detect deadlock.","title":"Pitfall #5: Lock Ordering Deadlock","description":"Thread A locks resource X then Y. Thread B locks Y then X. Both wait forever for the other's resource. Classic dining philosophers problem."}]},"type":"carousel"},{"data":{"fileName":"lock-ordering-deadlock.java","languages":[{"code":"$6c","label":"Deadlock Example","value":"java"}]},"type":"code"}],"titleType":"number","titleNumber":5},{"id":"performance-characteristics","title":"Performance Characteristics","content":[{"data":{"content":"Lock performance depends on contention level, critical section duration, and hardware factors. Understanding these trade-offs helps you choose the right lock type and optimize for your workload."},"type":"text"},{"data":{"rows":[["Basic Mutex","~25ns","~1-10μs","General purpose","Very short critical sections"],["Spin Lock","~5ns","Burns CPU","< 1μs hold time","Single core, long waits"],["Reentrant Lock","~30ns","~1-10μs","Nested locking","Performance-critical paths"],["Read-Write Lock","~35ns","~1-10μs","> 80% reads","Write-heavy workloads"],["Biased Lock","~1ns","~25ns first time","Thread-local access","High thread contention"]],"caption":"Lock Type Performance Comparison","headers":["Lock Type","Uncontended Cost","Contended Cost","Best For","Avoid When"]},"type":"table"},{"data":{"icon":"Info","title":"Contention Is The Killer","content":"Uncontended lock acquisition is remarkably cheap—often just a single atomic instruction. The real cost comes from contention: when threads must wait. Under high contention, the choice of lock type matters far less than reducing contention itself through better data structures or finer granularity.","variant":"note"},"type":"callout"},{"data":{"content":"**Key Performance Insights:**\n\n1. **Context switches dominate**: A sleeping lock's cost is primarily the ~1-10μs context switch, not the lock mechanism itself\n2. **Cache effects matter**: Locks involve memory barriers that flush CPU caches, impacting nearby data\n3. **False sharing is real**: Unrelated data on the same cache line forces synchronization between cores\n4. **Lock striping scales**: Instead of one lock for a hash map, use N locks (one per bucket range)\n5. **Adaptive locks exist**: Modern JVMs bias locks toward the last-owning thread, spin briefly before sleeping"},"type":"text"}],"titleType":"number","titleNumber":6},{"id":"summary","title":"Summary: Mutex Mastery","content":[{"data":{"content":"We've explored mutexes and locks from first principles to production patterns. Let's consolidate the key takeaways:"},"type":"text"},{"data":{"type":"ordered","items":["**Mutexes ensure mutual exclusion** — Only one thread can hold the lock; others block until it's released","**Always release locks in finally/RAII blocks** — Exception-safe locking prevents permanent deadlock","**Choose lock type for your use case** — Spin for microseconds, mutex for milliseconds, RW for read-heavy","**Minimize critical section size** — Hold locks for the shortest time possible to maximize concurrency","**Consistent lock ordering prevents deadlock** — Always acquire multiple locks in the same global order","**Memory visibility is a hidden benefit** — Locks provide happens-before guarantees beyond mutual exclusion"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nMutexes are powerful but limited to binary (locked/unlocked) states. The next page explores **Semaphores**—a generalization that allows controlling access to a limited number of resources, enabling patterns like connection pools, rate limiting, and bounded parallelism."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand mutexes and locks at a level sufficient for professional concurrent programming. You can select appropriate lock types, implement them correctly with exception safety, and avoid common pitfalls. Next, we'll explore semaphores—locks that count.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_949dd34b89c2d94539508e40d2e8e17a","title":"Semaphores: Counting-Based Synchronization","order":1,"content":null,"isLocked":true},{"id":"seed_e05b44e3b10370ec1512d2ab01bb236e","title":"Monitors: Structured Concurrency Coordination","order":2,"content":null,"isLocked":true},{"id":"seed_5afa8842e7b0b6e578dc1642030afb9f","title":"Choosing Synchronization Mechanisms","order":3,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792317979064,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"synchronization-primitives"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"synchronization-primitives\"},\"type\":\"query\"}]"},{"dehydratedAt":1792317979096,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792317979093,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_92960a7074a8134c2af152275a8f8a6f"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_92960a7074a8134c2af152275a8f8a6f\"},\"type\":\"query\"}]"},{"dehydratedAt":1792317979096,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792317979094,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","get"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_949dd34b89c2d94539508e40d2e8e17a"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_949dd34b89c2d94539508e40d2e8e17a\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792317979096,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792317979094,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","getUserLike"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_949dd34b89c2d94539508e40d2e8e17a"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_949dd34b89c2d94539508e40d2e8e17a\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792317979096,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792317979094,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["highlights","getHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_949dd34b89c2d94539508e40d2e8e17a"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_949dd34b89c2d94539508e40d2e8e17a\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792317979096,"state":{"data":"$undefined","dataUpdateCount":0,"dataUpdatedAt":0,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"pending","fetchStatus":"fetching"},"queryKey":[["highlights","getPopularHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_949dd34b89c2d94539508e40d2e8e17a","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_949dd34b89c2d94539508e40d2e8e17a\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@6d"}]},"children":"$L6e"}]