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

Rafael Brandão rblcin at gmail.com
Sat May 31 18:50:09 EDT 2014


Hello,

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~0.12.04.2) 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,
Rafael


[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/20140531/28816eac/attachment.html>


More information about the Concurrency-interest mailing list