Advanced Locking

1. The “Why” ReentrantLock is a manual alternative to synchronized. We use it when we need to break Coffman’s Conditions for deadlocks. Specifically: Breaking “No Preemption”: With tryLock(), if a thread can’t get the lock, it can walk away instead of hanging. Breaking “Uninterruptible Wait”: With lockInterruptibly(), we can stop a waiting thread externally using thread.interrupt(). 2. Comparison: synchronized vs. ReentrantLock Feature synchronized ReentrantLock Flexibility Low (Block-scoped only). High (Can start lock in one method, end in another). Fairness No (Random thread gets the lock). Optional (Can grant lock to the longest-waiting thread). Timeout Support No (Waits forever). Yes (tryLock). Interruptibility No (Cannot be interrupted while waiting). Yes (lockInterruptibly). Syntax Simple (Automatic cleanup). Complex (Requires manual unlock() in a finally block). 3. The “Golden” Snippet: The Safe Transfer (No Deadlock) This snippet uses tryLock() to attempt to acquire two locks. If it fails to get the second one, it “preempts” itself by releasing the first one and trying again later. ...

1. The “Why” In a UI application, responsiveness is king. If a background thread is performing a heavy database update or image processing, we don’t want the UI to “hang” while waiting for that data. ReentrantLock with tryLock() allows the UI thread to check: “Is the data ready? No? Okay, I’ll keep the loading spinner spinning and try again in the next frame.” 2. Comparison: Blocking vs. Non-Blocking UI Feature synchronized (Blocking) ReentrantLock.tryLock() User Experience App freezes (Not Responding) until lock is free. App remains responsive; can show a “Busy” message. Thread Behavior UI Thread is suspended by the OS. UI Thread continues its loop, handling other clicks. Timeout Support None. Can try for $X$ milliseconds and then give up. 3. The “Golden” Snippet: The Responsive UI Imagine a Dashboard that updates every second. If the “Database Thread” is currently writing to the shared PriceData object, the UI thread shouldn’t wait; it should just skip this update or show the old data. ...

1. The “Why” Standard locks (synchronized, ReentrantLock) are Mutual Exclusion locks—they don’t care if a thread is reading or writing; they block everyone else. ReentrantReadWriteLock recognizes that multiple threads reading the same data simultaneously is perfectly safe. It only enforces “Mutual Exclusion” when a thread needs to write (modify) the data. 2. Comparison: ReentrantLock vs. ReadWriteLock Feature ReentrantLock ReentrantReadWriteLock Read/Read Blocking (One at a time). Non-Blocking (Infinite simultaneous readers). Read/Write Blocking. Blocking (Reader waits for Writer). Write/Write Blocking. Blocking (Only one Writer at a time). Best Use Case General purpose, frequent updates. Databases, Caches, “Read-Heavy” metadata. 3. The “Golden” Snippet: A Simple Database In this example, we create a SimpleDatabase where many threads can query prices at the same time, but an update thread can safely modify them without causing data races. ...

The choice between a standard ReentrantLock and a ReentrantReadWriteLock usually comes down to one metric: the Read-to-Write ratio. If your threads are mostly looking at data without changing it, a standard lock creates a massive, unnecessary bottleneck. If your threads are constantly updating data, the overhead of a ReadWriteLock actually makes it slower than a simple lock. 1. Scenario A: High-Contention Updates (Use ReentrantLock) Scenario: A Counter or a Bank Account where every single thread that enters is there to modify the value (e.g., increment() or deposit()). ...