ReentrantLock - UI Application Example

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

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.

import java.util.concurrent.locks.ReentrantLock;

public class DashboardUI extends Thread {
    private final ReentrantLock dataLock = new ReentrantLock();
    private String priceInfo = "0.00";

    // BACKGROUND THREAD: Heavy Data Fetching
    public void updateDataFromNetwork() {
        dataLock.lock(); // Background thread can afford to wait
        try {
            Thread.sleep(5000); // Simulate slow network
            this.priceInfo = "125.50";
        } catch (InterruptedException e) {
            // Handle interrupt
        } finally {
            dataLock.unlock();
        }
    }

    // UI THREAD: Must stay responsive
    public void renderScreen() {
        // Instead of waiting, we "ask" for the lock
        if (dataLock.tryLock()) {
            try {
                System.out.println("UI Thread: Updating screen with: " + priceInfo);
            } finally {
                dataLock.unlock();
            }
        } else {
            // This is the "Aha!" moment: The UI doesn't freeze!
            System.out.println("UI Thread: Data busy. Showing 'Loading...' or old data.");
        }
    }
}

Code Explanation:

1. The Background Lock: The network thread uses .lock(). It needs to finish its job and can stay blocked as long as necessary because it doesn’t interact with the user.
2. The UI Check: The renderScreen() method (simulating the UI thread) uses tryLock().
3. The Branching Logic:
   • If true: The UI thread gets the data and updates the screen immediately.
   • If false: The UI thread immediately skips the block. It doesn’t wait 5 seconds; it returns instantly, allowing the application to process mouse clicks or window resizing.

Example Output:

[NetworkThread]: Fetching data... (Holding lock)
[UIThread]: Data busy. Showing 'Loading...' 
[UIThread]: Data busy. Showing 'Loading...' 
[NetworkThread]: Data updated. (Released lock)
[UIThread]: Updating screen with: 125.50

4. The Gotchas

• The Polling Frequency: If the UI thread calls tryLock() in a tight loop without any rest, it can consume 100% of the CPU. Always ensure the UI loop has a small “sleep” or is triggered by a timer.
• Complex State: If your UI needs to lock multiple resources (e.g., Price Data AND User Profile), ensure you use the “Lock Ordering” we discussed in the Deadlock section, even when using tryLock().
• State Visibility: While ReentrantLock handles visibility, remember that once you unlock(), the UI thread is looking at a “snapshot.” If the background thread changes the data a microsecond later, the UI won’t know until the next tryLock() attempt.