[concurrency-interest] Deadlock with when no threads have the lock
viktor.klang at gmail.com
Tue Jun 20 08:33:29 EDT 2017
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 <david.lloyd at redhat.com>
> 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:
>> scala/mesosphere/marathon/util/Lock.scala#L29-L30 - your equals method
>> can deadlock.
>> (not saying that this is the cause...)
>> On 16 Jun 2017, at 22:36, Ken Sipe <kensipe at gmail.com <mailto:
>>> kensipe at gmail.com>> 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
>>> Any thoughts on this?
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at c
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
> - DML
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest