[concurrency-interest] Potential threads getting stuck on WAITING(parking) in ReentrantLock

David Holmes davidcholmes at aapt.net.au
Sat May 31 19:55:18 EDT 2014

Hi Rafael,

Does this reproduce with Oracle JDK or only the IcedTea distributions?

The most likely issue is the StackOverflowError. Have excluded that possibility?

  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Rafael Brandão
  Sent: Sunday, 1 June 2014 8:50 AM
  To: concurrency-interest at cs.oswego.edu
  Subject: [concurrency-interest] Potential threads getting stuck on WAITING(parking) in ReentrantLock


  I'm working on a few changes for ReentrantLock to make A/B tests between the original implementation and my modifications, so my first step was to copy the sources of ReentrantLock, AbstractQueuedSynchronizer (shortly AQS) and AbstractOwnableSynchronizer and put them in a different package. After resolving basic compilation issues, I've found the issue with Unsafe usage (insecurity exception) and I've solved it based on the article found in [1]. So basically my ReentrantLock has nothing different from the original except for how I get the Unsafe in AQS.

  After that, I've exhaustively conducted the following experiment: 200 threads try to increment 1000 times each some integer counter protected by explicit locks. There are 10 counters, so each counter has 20 threads concurrently trying to increment it. The main thread spawns all those threads and then wait for them with join method. Once I've ran this experiment many times (about 30000), it consistently get stuck in a join for some thread when I use my almost unmodified ReentrantLock before 2000th attempt.

  I've got the thread stacks in [2] and what I understood from it is that the remaining threads are all stuck waiting for the lock to be released. However I've managed to print the owner of that lock and I see it's unlocked and has no owner:

    stuck thread state: WAITING
    thread waiting lock: safe.ReentrantLock at 68a6a21a[Unlocked]
    lock owner: null

  I've been trying to reproduce it with the original ReentrantLock but I didn't get stuck so far. So I'm here to ask you if there's a known issue on ReentrantLock that could cause this situation (and also be extremely unlikely to happen) or if there's something obvious that I should know about the Unsafe usage given it's the only thing changed so far.

  I suspect I have some disadvantage given that my nearly unmodified class is not already compiled in the JVM (I could try to build the JDK later), but this could only be a sign that the issue already exists in the code but can only become more likely to happen in a slower implementation. I've also searched for related bugs and the closest thing I've found was [3].

  I'm using a Intel® Core™ i7-3632QM notebook running Ubuntu 12.04. Java version is "1.7.0_55" and I'm using OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~ and OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode). I've experienced this issue after copying sources of jdk7u, jdk8u and jdk9.

  Best regards,

  [1] http://howtodoinjava.com/2013/10/19/usage-of-class-sun-misc-unsafe/
  [2] https://gist.github.com/rafaelbrandao/4ec5f2cd272c4b8b183a
  [3] https://bugs.openjdk.java.net/browse/JDK-8028686

  Rafael Brandão @ CIn - Center of Informatics 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140601/0f3fc3e3/attachment.html>

More information about the Concurrency-interest mailing list