ReentrantLock says "unlocked" but first thread stops

Question

We're calling "lock()" on a ReentrantLock and threads are getting stuck there when they apparently shouldn't.

When debugging with a breakpoint just before the call to "lock()", the first thread would stop there with the program pointer going to "Thread.exit()". The lock object's toString() says "unlocked" and it's "state" attribute is "0". The behavior is not always the same. Sometimes the first thread goes past the lock as expected.

    userLock.lock(); //first thread sometimes gets stuck here (and the following ones as well)
                     //"userLock" has "state=0" and toString() says "UNLOCKED"

    try {
        Transaction tr = HibernateConfig.getSessionFactory().getCurrentSession().beginTransaction();
        try {
            execute();
            tr.commit();
        } catch (ConstraintViolationException e) {
            //probably traces with repeated time
            System.err.println(e.getMessage());
            if (tr.isActive()) {
                tr.rollback();
            }
        } catch (RuntimeException e) {
            e.printStackTrace();
            if (tr.isActive()) {
                tr.rollback();
            }
        }
    } catch (Throwable e) {
        e.printStackTrace();
    } finally {
        userLock.unlock();
    }

This sounds unlikely. Perhaps there's another thread active which is stealing the lock just after you print its state? Perhaps try printing debug messages or setting breakpoints at _every_ possible location the lock can become locked. — davmac, Aug 22 '13 at 12:19
There's no other lock. We've put a breakpoint before it, so it should be getting every thread that could possibly lock it. I didn't print the state but got it from the debugging gui while my thread was in the breakpoint. — Victor Basso, Aug 22 '13 at 12:49

score 1 · Answer 1 · answered Aug 22 '13 at 13:39

1

try to put a breakpoint after userLock.lock(); then you should get the thread, that gets the lock. alternatively you could use userLock.getOwner(); right behind .lock() to see wich thread got the lock.

answered Aug 22 '13 at 13:39

JohnnyAW

2,866
1
16
27

score 0 · Answer 2 · answered Aug 22 '13 at 15:23

The problem was my breakpoint was not before "lock()" like I said, but on it. What happened is a bunch of threads would be blocked in that line by the breakpoint, one of them would still acquire the lock, and then the debugger would give me control over a random one of them which hadn't acquired the lock. And I was failing to check every thread blocked by the breakpoint to find the free one.

In the end I put the breakpoint actually before the lock and it behaved as expected. This was confusing and I hope the question will still help someone.

Note: I'm still confused by the fact the lock's state said "unlocked" in the debugger while I was controlling a locked thread.

This still doesn't really make sense; if you have a breakpoint on a line, the breakpoint should trigger _before_ the line is executed, not after. I wonder if what you've got here is a subtle JVM/JPDA bug. — davmac, Aug 23 '13 at 11:23

ReentrantLock says "unlocked" but first thread stops

2 Answers2