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

Rafael Brandão rblcin at gmail.com
Mon Jun 2 21:43:34 EDT 2014


Hello,

David, I have now tested it with java version "1.8.0_05", Java(TM) SE
Runtime Environment (build 1.8.0_05-b13) and Java HotSpot(TM) 64-Bit Server
VM (build 25.5-b02, mixed mode). The problem with my nearly unmodified
ReentrantLock getting stuck is no longer happening when I run the
experiment. Would you also like me to test with any particular version?
Thanks for the tip! Now about StackOverflowError, I don't see how it could
be possible (I've posted a link to the code if you want to check), since
there's no infinite recursion for example and each test run is relatively
low in used resources.

Heinz, I have posted the code on https://github.com/rafaelbrandao/msc - the
latest commit message (it only has 3 commits) contains information on how
to reproduce this issue. It seems to be fixed when I use Oracle JDK 8
however.

What could be causing the stuck threads? Is it possible this is a problem
with the ReentrantLock algorithm/implementation?

Best regards,
Rafael

On Sun, Jun 1, 2014 at 2:07 AM, Dr Heinz M. Kabutz <heinz at javaspecialists.eu
> wrote:

> Please send us a link to your code, both your ReentrantLock and the test
> code?
>
> On 01/06/2014, David Holmes <davidcholmes at aapt.net.au> wrote:
> > Hi Rafael,
> >
> > Does this reproduce with Oracle JDK or only the IcedTea distributions?
> >
> > The most likely issue is the StackOverflowError. Have excluded that
> > possibility?
> >
> > David
> >   -----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
> >
> >
> >   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(R) Core(tm) 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
>
>
> --
> Dr Heinz M. Kabutz (PhD CompSci)
> Author of "The Java(tm) Specialists' Newsletter"
> Sun/Oracle Java Champion 2005-2013
> JavaOne Rockstar Speaker 2012
> http://www.javaspecialists.eu
> Tel: +30 69 75 595 262
> Skype: kabutz
>



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


More information about the Concurrency-interest mailing list