Advanced Locking on Study Notes

ReentrantLock - tryLock & Interruptibility

Fri, 27 Mar 2026 00:00:00 +0000

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.

ReentrantLock - UI Application Example

Fri, 27 Mar 2026 00:00:00 +0000

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.

ReentrantReadWriteLock & Database Implementation

Fri, 27 Mar 2026 00:00:00 +0000

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.

UseCase Scenario For Reentrant & ReentrantReadWrite Lock

Fri, 27 Mar 2026 00:00:00 +0000

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()).

Advanced Locking on Study Notes

ReentrantLock - tryLock & Interruptibility

1. The “Why”

2. Comparison: synchronized vs. ReentrantLock

3. The “Golden” Snippet: The Safe Transfer (No Deadlock)

ReentrantLock - UI Application Example

1. The “Why”

2. Comparison: Blocking vs. Non-Blocking UI

3. The “Golden” Snippet: The Responsive UI

ReentrantReadWriteLock & Database Implementation

1. The “Why”

2. Comparison: ReentrantLock vs. ReadWriteLock

3. The “Golden” Snippet: A Simple Database

UseCase Scenario For Reentrant & ReentrantReadWrite Lock

1. Scenario A: High-Contention Updates (Use ReentrantLock)

2. Comparison: `synchronized` vs. `ReentrantLock`

1. Scenario A: High-Contention Updates (Use `ReentrantLock`)