Java 8 Stamped Lock: Why this piece of code doesnt result into a deadlock?

Question

In my attempt to understand Optimistic locking in Java 8,I came across the below piece of code. Original Blog Here.

As explained in the blog, this piece of code is attempting to convert a read lock into a write lock.The code requests an explicit write lock if conversion of read lock to write lock failed.

It puzzles me How can it be expected that the explicit write lock get granted when the parent thread is already holding a read lock? It doesn't look like the read lock is getting released at any point before a write lock is forcefully requested. To my flawed understanding, the thread would wait infinitely for write lock as the read lock is never released creating a deadlock.

Why this doesn't result in a deadlock here?

ExecutorService executor = Executors.newFixedThreadPool(2);
StampedLock lock = new StampedLock();

executor.submit(() -> {
    long stamp = lock.readLock();
    try {
        if (count == 0) {
            stamp = lock.tryConvertToWriteLock(stamp);
            if (stamp == 0L) {
                System.out.println("Could not convert to write lock");
                stamp = lock.writeLock();
            }
            count = 23;
        }
        System.out.println(count);
    } finally {
        lock.unlock(stamp);
    }
});

stop(executor);

Thanks in advance!

Babby

Its more a theoretical question actually. Why the writelock gets granted when the thread is already holding a readlock given that Stampedlocks are non reentrant? I do not face any problem with this piece of code.Just trying to understand the reasoning explained in the blog. – Babby

To all readers, Here's the same issue highlighted differently and with an answer https://mcmap.net/q/1520127/-does-stampedlock-writelock-release-a-read-lock-held-by-the-current-thread/3835632 – Babby

Answer 1

Does this help? From the API for tryConvertToWriteLock

If the lock state matches the given stamp, atomically performs one of the following actions. If the stamp represents holding a write lock, returns it. Or, if a read lock, if the write lock is available, releases the read lock and returns a write stamp. Or, if an optimistic read, returns a write stamp only if immediately available. This method returns zero in all other cases.

Ravelment

So here, in the case I am highlighting, write lock isnt available. So this returns a zero timestamp. The code should then asks for a write lock. As I understand it, the write lock wouldnt be granted unless the read lock is released which is held by the same thread leading to deadlock. Only possibility I can imagine is tryConvertToWriteLock causes release of read lock when it is called even if conversion is not successful. – Babby

Here's the answer https://mcmap.net/q/1520127/-does-stampedlock-writelock-release-a-read-lock-held-by-the-current-thread – Babby