Locks You Can Give Up On

ReentrantLock is synchronized with the missing methods.

private final ReentrantLock lock = new ReentrantLock();

lock.lock();
try {
    counter++;
} finally {
    lock.unlock();        // you must do this. Nothing else will.
}

Verified against a held lock:

tryLock()            : false
tryLock(200ms)       : false
lockInterruptibly    : interrupted out of waiting

That third line is the one synchronized cannot do at all.

ReadWriteLock lets readers share.

private final ReadWriteLock rw = new ReentrantReadWriteLock();

// many at once
rw.readLock().lock();
try { return config.get(key); } finally { rw.readLock().unlock(); }

// one, and no readers
rw.writeLock().lock();
try { config.put(key, value); } finally { rw.writeLock().unlock(); }

Any number of readers, or one writer, never both.

And now the measurement, which does not say what you expect. Eight reader threads, nothing writing:

On short reads the read write lock is seventeen times slower. On long ones it is six times faster.

A read lock has to count how many readers are inside, and that count is shared, so entering and leaving are atomic updates that eight threads contend for. When the read itself is one array access, the accounting is nearly all the work.

The crossover here is somewhere between 256 and 4096 integers, and it is a property of this machine and this workload. The only honest rule is that a read write lock is worth it when reads are long, and a pessimisation when they are short.

Semaphore counts permits.

private final Semaphore slots = new Semaphore(3);

slots.acquire();
try { callExternalService(); } finally { slots.release(); }

semaphore permits    : 3
after two acquires   : 1
tryAcquire(4)        : false

Three threads through at a time. A Semaphore(1) is a lock, with one difference worth knowing: any thread can release a permit, including one that never acquired it. It is a counter, not an owner.

Condition splits the wait set.

private final Lock lock = new ReentrantLock();
private final Condition notFull  = lock.newCondition();
private final Condition notEmpty = lock.newCondition();

// producer
lock.lock();
try {
    while (queue.size() == capacity) notFull.await();
    queue.add(item);
    notEmpty.signal();          // wake a CONSUMER, not everyone
} finally { lock.unlock(); }

await and signal are wait and notify with different names, and the difference is that one lock can have several conditions. Producers wait on one, consumers on the other, and a signal reaches only the group that cares.

That is the answer to notifyAll waking everybody, and the same while loop rule from Section 14.6 still applies.

Answer from memory before opening the explanation. Then compare your rule with the answer and revisit the example if they differ.

1. What can a `ReentrantLock` do that `synchronized` cannot?

   Show the answer

   Four things, and each one answers a real gap.

   Give up. tryLock() returns false at once if the lock is held, so a thread can do something else instead of waiting.

   Wait with a deadline. tryLock(200, MILLISECONDS) waits and then gives up.

   Be interrupted. lockInterruptibly() throws InterruptedException while waiting. A thread waiting on synchronized ignores interruption completely, which is the gap from Section 14.3.

   Be fair. new ReentrantLock(true) hands the lock to whoever has waited longest, instead of whoever the scheduler happens to pick.

   The price is that you must release it yourself, in a finally, every time.

2. Why must an explicit lock be unlocked in a `finally` block?

   Show the answer

   Because nothing else will do it. synchronized releases its monitor automatically when the block ends, including when an exception is thrown.

   lock.lock() has no block and no end, so if the code between it and unlock() throws, the lock is never released. Every other thread that wants it waits forever, and the program stops with no error to explain it.

   So the shape is fixed and there is no variation on it:

   lock.lock(); try { ... } finally { lock.unlock(); }

   The lock() call goes before the try. Putting it inside means an unlock that runs when the lock was never acquired.

3. A `ReadWriteLock` lets many readers in at once. Why was it seventeen times slower than an exclusive lock in the measurement?

   Show the answer

   Because letting readers in costs bookkeeping, and the reads were too short to be worth it.

   A read lock has to track how many readers are inside, which means an atomic update on the way in and another on the way out. When the read itself is one array access, that accounting is nearly all of the work, and eight threads fighting over the counter is worse than eight threads queueing politely.

   Measured, eight readers: reading 1 int took 40 ms exclusive and 470 ms with a read write lock. Reading 4096 ints took 564 ms exclusive and 94 ms with the read write lock.

   So it wins when reads are long enough to overlap usefully. On short reads it is a pessimisation, and nothing in the code tells you which case you are in.

Write each solution in VS Code, predict its result, and then run the checks. Reading an example does not replace implementing it.

4 exercises105 pointsabout 105 minutes

import java.util.concurrent.*;
import java.util.concurrent.locks.*;

public class GiveUp {
    static final ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) throws Exception {
        // TODO: hold the lock on main. From another thread try:
        //   tryLock(), tryLock(200ms), lockInterruptibly() then interrupt it
        // TODO: print what each one did
        // TODO: try the same three things with synchronized. Which are possible?
        // TODO: build a fair lock and an unfair one, run eight threads through each,
        //       and compare both the timing and how evenly the turns were shared
    }
}

import java.util.concurrent.locks.*;

public class Crossover {
    static int[] data = new int[4096];

    static long readWork(int len) {
        long s = 0;
        for (int i = 0; i < len; i++) s += data[i];
        return s;
    }

    public static void main(String[] args) throws Exception {
        // TODO: eight reader threads, nothing writing. Compare an exclusive
        //       ReentrantLock against a ReadWriteLock's read lock.
        // TODO: do it at read lengths of 1, 16, 256 and 4096 ints
        // TODO: warm both up before timing
        // TODO: find roughly where the crossover is on YOUR machine
        // TODO: now add one writer and see what changes
    }
}

import java.util.*;
import java.util.concurrent.locks.*;

public class TwoGroups {
    // TODO: a bounded buffer using ReentrantLock and TWO Conditions:
    //   notFull  for producers
    //   notEmpty for consumers

    public static void main(String[] args) throws Exception {
        // TODO: count how many times a thread wakes up with nothing to do,
        //       in your Condition version
        // TODO: write the same buffer with synchronized and notifyAll,
        //       and count the same thing
        // TODO: run both with four producers and four consumers
        // TODO: say what you would have to give up to use notify() instead
    }
}

import java.util.concurrent.locks.*;

public class NeverUnlocked {
    static final ReentrantLock lock = new ReentrantLock();

    static void broken(int i) {
        lock.lock();
        if (i == 3) throw new IllegalStateException("boom");
        lock.unlock();
    }

    public static void main(String[] args) throws Exception {
        // TODO: call broken() a few times, catching the exception, then have
        //       another thread try to take the lock. What happens?
        // TODO: print lock.isLocked() and lock.getHoldCount()
        // TODO: fix it with try/finally
        // TODO: write the same broken shape with synchronized. Does it break?
        // TODO: put lock() INSIDE the try and say what goes wrong with that
    }
}