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

David Holmes davidcholmes at aapt.net.au
Mon Jun 2 23:25:32 EDT 2014


Maybe not so weird given that the bug was only ever observed using Semaphore and running a specific test case.

Race conditions are very fickle beasts :)

David
  -----Original Message-----
  From: Rafael Brandão [mailto:rblcin at gmail.com]
  Sent: Tuesday, 3 June 2014 1:21 PM
  To: dholmes
  Cc: Dr Heinz M. Kabutz; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Potential threads getting stuck on WAITING(parking) in ReentrantLock


  I can also reproduce this issue with java version "1.7.0_60": Java(TM) SE Runtime Environment (build 1.7.0_60-b19) and Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode). It could be that bug then, thanks David. :-)


  I still find it weird how I can only reproduce this issue with my ReentrantLock and not with the default ReentrantLock so far. If I understood correctly this was a problem on AQS, so in theory I should get stuck using the default ReentrantLock as well.


  Thanks for your help!


  Best regards,
  Rafael



  On Mon, Jun 2, 2014 at 11:35 PM, David Holmes <davidcholmes at aapt.net.au> wrote:

    Hi Rafael,

    Can you try Oracle JDK 7? This might be:

    https://bugs.openjdk.java.net/browse/JDK-7011859

    which was fixed in 8.

    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: Tuesday, 3 June 2014 11:44 AM
      To: Dr Heinz M. Kabutz
      Cc: concurrency-interest at cs.oswego.edu; dholmes at ieee.org
      Subject: Re: [concurrency-interest] Potential threads getting stuck on WAITING(parking) in ReentrantLock


      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 





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


More information about the Concurrency-interest mailing list