current j.u.c updates

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

current j.u.c updates

Doug Lea

The current versions of jsr166 classes are now updated to use VarHandles,
onSpinWait, and other jdk9 stuff, so are approaching their expected
jdk9 form.

If you'd like to help your future self, please try it out
and let us know of any problems.  It would be nice to hear
about issues before we integrate with openjdk (soon).

To use it, you need at  least jdk9 build 120. You can get it from
   https://jdk9.java.net/download/
and then get jsr166.jar at
   http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar
and run using
   java -Xpatch:java.base="$DIR/jsr166.jar"
where DIR is the full file prefix.
(Note that these instructions are different than they were for
earlier jdk9 builds.)

Instead of getting the jar, you can get sources at build yourself
   http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166.tar.gz?view=tar
then cd into jsr166 and "ant jar" and "ant tck" to run basic unit tests.
Building javadocs will fail with assertion error that we think
will be fixed soon in openjdk.

For the curious, VarHandles replace all uses of Unsafe except
(1) those in ConcurrentHashMap, to avoid bootstrap circularities
when class loaders and method handles need CHM, and (2) those
accessing Thread class fields (in ThreadLocalRandom, Locks.LockSupport,
and atomic/Striped64).

Bear in mind whan comparing to jdk8 performance that the G1 garbage
collector is now default in jdk9, which tends cause slowdowns in some
concurrent applications (but may still be preferable because of
reduced latencies.) Use "-XX:+UseParallelGC", for jdk8-like GC,
with -XX:+UseCondCardMark to reduce false sharing.

Also, if you haven't yet, you might want to try out (jdk9)
Flow and SubmissionPublisher.


-Doug




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Deadlock with when no threads have the lock

Ken Sipe
We have encountered a strange deadlock scenario in which it appears that all threads are waiting on acquiring a ReentrantLock, but no thread has the lock. 

Any thoughts on this?



Thanks,
ken



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

Kirk Pepperdine
Hi Ken,

If you have a lock with nothing holding on to it then either a VM thread has the lock. The most common culprit are GC threads. I’ve not taken a deep look at the code but you could set -XX:+PrintConcurrentLocks which would give you an idea if the problem is with the re-enterant lock. Not looked too deeply at the code but I don’t see anything obvious at the moment.

— Kirk

On Jun 16, 2017, at 11:36 PM, Ken Sipe <[hidden email]> wrote:

We have encountered a strange deadlock scenario in which it appears that all threads are waiting on acquiring a ReentrantLock, but no thread has the lock. 

Any thoughts on this?



Thanks,
ken


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

Henri Tremblay
If you keep doing thread dumps, is the lock and the waiting threads the same? So a real deadlock. If yes, Kirk suggestion is interesting. And I would also do a heap dump to have a look at the threads holding a reference to the reentrant lock.

On 16 June 2017 at 18:55, Kirk Pepperdine <[hidden email]> wrote:
Hi Ken,

If you have a lock with nothing holding on to it then either a VM thread has the lock. The most common culprit are GC threads. I’ve not taken a deep look at the code but you could set -XX:+PrintConcurrentLocks which would give you an idea if the problem is with the re-enterant lock. Not looked too deeply at the code but I don’t see anything obvious at the moment.

— Kirk

On Jun 16, 2017, at 11:36 PM, Ken Sipe <[hidden email]> wrote:

We have encountered a strange deadlock scenario in which it appears that all threads are waiting on acquiring a ReentrantLock, but no thread has the lock. 

Any thoughts on this?



Thanks,
ken


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

Kirk Pepperdine
There are 94 threads that appear to be waiting on 2 different locks. 47 are waiting on a ForkJoinExecutor and are simply idle. From this one would hope that you were on a 48 core machine.

As an example….
"marathon-akka.actor.default-dispatcher-35" #271 prio=5 os_prio=0 tid=0x00007ff868004000 nid=0x11fd4 runnable [0x00007ff8a9be0000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <a href="monitor://&lt;0x00000005c0581aa0&gt;" class=""><0x00000005c0581aa0> (a akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinPool)
	at scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:2075)
	at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
	at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

26 are waiting on a ReentantLock. These are probably the threads of interest.

"ForkJoinPool-2-worker-33" #25346 daemon prio=5 os_prio=0 tid=0x00007ff80c11c000 nid=0x5747 waiting on condition [0x00007ff8a91d8000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <a href="monitor://&lt;0x00000005c0af6298&gt;" class=""><0x00000005c0af6298> (a java.util.concurrent.locks.ReentrantLock$FairSync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
	at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
	at mesosphere.marathon.util.RichLock$.apply$extension(Lock.scala:7)
	at mesosphere.marathon.util.Lock.apply(Lock.scala:25)
	at mesosphere.marathon.util.KeyedLock.apply(WorkQueue.scala:94)

Are you waiting on an external signal?

— Kirk




On Jun 17, 2017, at 6:03 AM, Henri Tremblay <[hidden email]> wrote:

If you keep doing thread dumps, is the lock and the waiting threads the same? So a real deadlock. If yes, Kirk suggestion is interesting. And I would also do a heap dump to have a look at the threads holding a reference to the reentrant lock.

On 16 June 2017 at 18:55, Kirk Pepperdine <[hidden email]> wrote:
Hi Ken,

If you have a lock with nothing holding on to it then either a VM thread has the lock. The most common culprit are GC threads. I’ve not taken a deep look at the code but you could set -XX:+PrintConcurrentLocks which would give you an idea if the problem is with the re-enterant lock. Not looked too deeply at the code but I don’t see anything obvious at the moment.

— Kirk

On Jun 16, 2017, at 11:36 PM, Ken Sipe <[hidden email]> wrote:

We have encountered a strange deadlock scenario in which it appears that all threads are waiting on acquiring a ReentrantLock, but no thread has the lock. 

Any thoughts on this?



Thanks,
ken


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

Viktor Klang
There's the possibility that a task which unlocks the lock is stuck in the executor's submission queue because all the workers are blocked on obtaining the lock.

--
Cheers,

On Jun 17, 2017 8:13 AM, "Kirk Pepperdine" <[hidden email]> wrote:
There are 94 threads that appear to be waiting on 2 different locks. 47 are waiting on a ForkJoinExecutor and are simply idle. From this one would hope that you were on a 48 core machine.

As an example….
"marathon-akka.actor.default-dispatcher-35" #271 prio=5 os_prio=0 tid=0x00007ff868004000 nid=0x11fd4 runnable [0x00007ff8a9be0000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000005c0581aa0> (a akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinPool)
	at scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:2075)
	at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
	at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

26 are waiting on a ReentantLock. These are probably the threads of interest.

"ForkJoinPool-2-worker-33" #25346 daemon prio=5 os_prio=0 tid=0x00007ff80c11c000 nid=0x5747 waiting on condition [0x00007ff8a91d8000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000005c0af6298> (a java.util.concurrent.locks.ReentrantLock$FairSync)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
	at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
	at mesosphere.marathon.util.RichLock$.apply$extension(Lock.scala:7)
	at mesosphere.marathon.util.Lock.apply(Lock.scala:25)
	at mesosphere.marathon.util.KeyedLock.apply(WorkQueue.scala:94)

Are you waiting on an external signal?

— Kirk




On Jun 17, 2017, at 6:03 AM, Henri Tremblay <[hidden email]> wrote:

If you keep doing thread dumps, is the lock and the waiting threads the same? So a real deadlock. If yes, Kirk suggestion is interesting. And I would also do a heap dump to have a look at the threads holding a reference to the reentrant lock.

On 16 June 2017 at 18:55, Kirk Pepperdine <[hidden email]> wrote:
Hi Ken,

If you have a lock with nothing holding on to it then either a VM thread has the lock. The most common culprit are GC threads. I’ve not taken a deep look at the code but you could set -XX:+PrintConcurrentLocks which would give you an idea if the problem is with the re-enterant lock. Not looked too deeply at the code but I don’t see anything obvious at the moment.

— Kirk

On Jun 16, 2017, at 11:36 PM, Ken Sipe <[hidden email]> wrote:

We have encountered a strange deadlock scenario in which it appears that all threads are waiting on acquiring a ReentrantLock, but no thread has the lock. 

Any thoughts on this?



Thanks,
ken


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

Stuart Monteith
I've encountered a similar issue before with park/Unpark. There was
bug where class loading had a hand in causing Unparks to be missed:
    https://bugs.openjdk.java.net/browse/JDK-8074773

There can only be one outstanding unpark at a time, so subsequent
unparks can be lost.


BR,
   Stuart

On 17 June 2017 at 08:34, Viktor Klang <[hidden email]> wrote:

> There's the possibility that a task which unlocks the lock is stuck in the
> executor's submission queue because all the workers are blocked on obtaining
> the lock.
>
> --
> Cheers,
> √
>
> On Jun 17, 2017 8:13 AM, "Kirk Pepperdine" <[hidden email]> wrote:
>>
>> There are 94 threads that appear to be waiting on 2 different locks. 47
>> are waiting on a ForkJoinExecutor and are simply idle. From this one would
>> hope that you were on a 48 core machine.
>>
>> As an example….
>>
>> "marathon-akka.actor.default-dispatcher-35" #271 prio=5 os_prio=0
>> tid=0x00007ff868004000 nid=0x11fd4 runnable [0x00007ff8a9be0000]
>>    java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for  <0x00000005c0581aa0> (a
>> akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinPool)
>> at scala.concurrent.forkjoin.ForkJoinPool.scan(ForkJoinPool.java:2075)
>> at
>> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
>> at
>> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>>
>>
>> 26 are waiting on a ReentantLock. These are probably the threads of
>> interest.
>>
>> "ForkJoinPool-2-worker-33" #25346 daemon prio=5 os_prio=0
>> tid=0x00007ff80c11c000 nid=0x5747 waiting on condition [0x00007ff8a91d8000]
>>    java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for  <0x00000005c0af6298> (a
>> java.util.concurrent.locks.ReentrantLock$FairSync)
>> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>> at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
>> at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
>> at
>> java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224)
>> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
>> at mesosphere.marathon.util.RichLock$.apply$extension(Lock.scala:7)
>> at mesosphere.marathon.util.Lock.apply(Lock.scala:25)
>> at mesosphere.marathon.util.KeyedLock.apply(WorkQueue.scala:94)
>>
>>
>> Are you waiting on an external signal?
>>
>>
>> — Kirk
>>
>>
>>
>>
>>
>> On Jun 17, 2017, at 6:03 AM, Henri Tremblay <[hidden email]>
>> wrote:
>>
>> If you keep doing thread dumps, is the lock and the waiting threads the
>> same? So a real deadlock. If yes, Kirk suggestion is interesting. And I
>> would also do a heap dump to have a look at the threads holding a reference
>> to the reentrant lock.
>>
>> On 16 June 2017 at 18:55, Kirk Pepperdine <[hidden email]> wrote:
>>>
>>> Hi Ken,
>>>
>>> If you have a lock with nothing holding on to it then either a VM thread
>>> has the lock. The most common culprit are GC threads. I’ve not taken a deep
>>> look at the code but you could set -XX:+PrintConcurrentLocks which would
>>> give you an idea if the problem is with the re-enterant lock. Not looked too
>>> deeply at the code but I don’t see anything obvious at the moment.
>>>
>>> — Kirk
>>>
>>> On Jun 16, 2017, at 11:36 PM, Ken Sipe <[hidden email]> wrote:
>>>
>>> We have encountered a strange deadlock scenario in which it appears that
>>> all threads are waiting on acquiring a ReentrantLock, but no thread has the
>>> lock.
>>>
>>> Any thoughts on this?
>>>
>>> https://gist.github.com/timcharper/9ab4fea9da4669e620507e85e764d94a
>>>
>>>
>>> Thanks,
>>> ken
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>>
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> [hidden email]
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

Alex Otenko
In reply to this post by Ken Sipe

(not saying that this is the cause...)

Alex


On 16 Jun 2017, at 22:36, Ken Sipe <[hidden email]> wrote:

We have encountered a strange deadlock scenario in which it appears that all threads are waiting on acquiring a ReentrantLock, but no thread has the lock. 

Any thoughts on this?



Thanks,
ken


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

David M. Lloyd-3
You say *all* threads, but it's not true: all threads are not waiting on
the lock.

Aside from that though, if threads are waiting, then a thread must own
the lock, and furthermore it must be a thread that is not waiting on the
lock (because they're reentrant and such an acquisition would have
succeeded and would appear in the stack trace).  So, somehow the scala
block may have failed in a way that prevented the finally block from
running (stack overflow maybe, or maybe some Scala bug).

It should be possible to reflectively invoke the "getOwner()" method of
the ReentrantLock to see what thread had acquired the lock.

On 06/20/2017 06:23 AM, Alex Otenko wrote:

> https://github.com/mesosphere/marathon/blob/v1.4.2/src/main/scala/mesosphere/marathon/util/Lock.scala#L29-L30 -
> your equals method can deadlock.
>
> (not saying that this is the cause...)
>
> Alex
>
>
>> On 16 Jun 2017, at 22:36, Ken Sipe <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> We have encountered a strange deadlock scenario in which it appears
>> that all threads are waiting on acquiring a ReentrantLock, but no
>> thread has the lock.
>>
>> Any thoughts on this?
>>
>> https://gist.github.com/timcharper/9ab4fea9da4669e620507e85e764d94a
>>
>>
>> Thanks,
>> ken
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> [hidden email]
>> <mailto:[hidden email]>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


--
- DML
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

Viktor Klang
As an aside, to avoid deadlocks for that `equals`-implementation, you need to make sure that all comparisons take the locks in the same order, so like, the one with the lowest identityHashCode or something like that.

(as well as special casing the situation where `o` == this)

On Tue, Jun 20, 2017 at 2:14 PM, David M. Lloyd <[hidden email]> wrote:
You say *all* threads, but it's not true: all threads are not waiting on the lock.

Aside from that though, if threads are waiting, then a thread must own the lock, and furthermore it must be a thread that is not waiting on the lock (because they're reentrant and such an acquisition would have succeeded and would appear in the stack trace).  So, somehow the scala block may have failed in a way that prevented the finally block from running (stack overflow maybe, or maybe some Scala bug).

It should be possible to reflectively invoke the "getOwner()" method of the ReentrantLock to see what thread had acquired the lock.

On 06/20/2017 06:23 AM, Alex Otenko wrote:
https://github.com/mesosphere/marathon/blob/v1.4.2/src/main/scala/mesosphere/marathon/util/Lock.scala#L29-L30 - your equals method can deadlock.

(not saying that this is the cause...)

Alex


On 16 Jun 2017, at 22:36, Ken Sipe <[hidden email] <mailto:[hidden email]>> wrote:

We have encountered a strange deadlock scenario in which it appears that all threads are waiting on acquiring a ReentrantLock, but no thread has the lock.

Any thoughts on this?

https://gist.github.com/timcharper/9ab4fea9da4669e620507e85e764d94a


Thanks,
ken


_______________________________________________
Concurrency-interest mailing list
[hidden email] <mailto:[hidden email]>
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
- DML

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deadlock with when no threads have the lock

Stephan Diestelhorst
In reply to this post by David M. Lloyd-3
(Transferring some knowledge from other domains)

I've seen a case where no one had the lock, yet the application was deadlocking.  The thing that caused it then was a lost wakeup from the last guy freeing the lock needing to prod the threads that wanted to enter the lock, but stopped spinning on it (and went to sleep, got stashed away, get marked as blocked).

Is there any chance the same thing could be happening here?

Stephan

On 20 June 2017 at 13:14, David M. Lloyd <[hidden email]> wrote:
You say *all* threads, but it's not true: all threads are not waiting on the lock.

Aside from that though, if threads are waiting, then a thread must own the lock, and furthermore it must be a thread that is not waiting on the lock (because they're reentrant and such an acquisition would have succeeded and would appear in the stack trace).  So, somehow the scala block may have failed in a way that prevented the finally block from running (stack overflow maybe, or maybe some Scala bug).

It should be possible to reflectively invoke the "getOwner()" method of the ReentrantLock to see what thread had acquired the lock.

On 06/20/2017 06:23 AM, Alex Otenko wrote:
https://github.com/mesosphere/marathon/blob/v1.4.2/src/main/scala/mesosphere/marathon/util/Lock.scala#L29-L30 - your equals method can deadlock.

(not saying that this is the cause...)

Alex


On 16 Jun 2017, at 22:36, Ken Sipe <[hidden email] <mailto:[hidden email]>> wrote:

We have encountered a strange deadlock scenario in which it appears that all threads are waiting on acquiring a ReentrantLock, but no thread has the lock.

Any thoughts on this?

https://gist.github.com/timcharper/9ab4fea9da4669e620507e85e764d94a


Thanks,
ken


_______________________________________________
Concurrency-interest mailing list
[hidden email] <mailto:[hidden email]>
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
- DML

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Loading...