Locking Problem with Lazy Striped ReadWriteLocks

We’re seeing a behaviour of a Striped.lazyReadWriteLock that seem to break the documented behaviour that for the same key the same lock will be returned. Is there something obvious we’re missing or misunderstood about the lazy Striped Locks? When using eager Locks, everything works as expected.

The following test reproduces the behaviour.

public class MyTest {

    private final Striped<ReadWriteLock> stripedLock = Striped.lazyWeakReadWriteLock(64);
    private final AtomicBoolean writeLocked = new AtomicBoolean(false);
    private final Set<String> someSet = new HashSet<>();
    private final Random random = new Random();

    private final String key = "anyKey";

    @Test
    public void test() throws Exception {
        final ExecutorService executorService = Executors.newCachedThreadPool();
        final AtomicBoolean testFailed = new AtomicBoolean(false);

        for (int i = 0; i < 1000000; i++) {
            someSet.add("" + i);
        }

        for (int i = 0; i < 10; i++) {

            executorService.submit(new Runnable() {
                @Override
                public void run() {
                    try {
                        while (!testFailed.get()) {
                            if (random.nextBoolean()) {
                                writeLockedMethod();
                            } else {
                                readLockedMethod();
                            }
                        }
                    } catch (AssertionError e) {
                        e.printStackTrace();
                        testFailed.set(true);
                    }
                }
            });
        }

        while (!testFailed.get()) {
            Thread.sleep(1000);
        }
        fail();
    }

    private void readLockedMethod() {
        final Lock readLock = stripedLock.get(key).readLock();
        readLock.lock();
        assertFalse(writeLocked.get());
        try {
            someSet.contains("" + random.nextInt(1000000)); //Just do something.
        } finally {
            readLock.unlock();
        }
    }

    private void writeLockedMethod() {
        final Lock writeLock = stripedLock.get(key).writeLock();
        writeLock.lock();
        //Since the atomic boolean is set inside the write lock, for the same key, this should never be true.
        assertFalse(Thread.currentThread().getName(),writeLocked.get());
        writeLocked.getAndSet(true);
        try {
            someSet.contains("" + random.nextInt(1000000)); //Just do something.
        } finally {
            writeLocked.getAndSet(false);
            writeLock.unlock();
        }
    }
}

[lowasser]

As surprising as this behavior is, I think it’s…technically…spec-compliant. Took me a couple minutes to figure it out. That doesn’t mean it’s not unacceptably surprising, or fixable, though.

The issue isn’t the laziness, it’s the weak part. The lock is weakly referenced by the Striped; it says so in the “weak” part of the method name.

The issue is that those two methods of yours don’t hold on to the ReadWriteLock itself. They hold on to the read lock and to the write lock. Separately. And those don’t hold references back to the ReadWriteLock. So the ReadWriteLock is eligible for garbage collection in the middle of the method, and a new one gets generated the next time someone asks for it, and since it’s not the same lock they interoperate at the same time.

That said: that’s an artifact of the Java implementation of ReentrantReadWriteLock, that the read and write locks don’t actually hold references back to the shared lock object they came from. And it makes lazyWeakReadWriteLock almost useless. So I think the proper thing to do is, in fact, to return not a ReentrantReadWriteLock but a thin wrapper that makes sure the read and write locks hold references to the ReadWriteLock they came from.

[efge]

https://bugs.openjdk.java.net/browse/JDK-8189598