Real-world Pinning/ReentrantLock deadlock

[Danny Thomas]

Working on looking at the scheduler, poller and locking changes as we
speak.

On Tue, 25 Jun 2024 at 4:21 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 25/06/2024 02:13, Danny Thomas wrote:
> > Hi folks,
> >
> > We ran into a real-world deadlock with virtual threads and Micrometer,
> > Brave/Zipkin. In short, there are two paths to
> > CountBoundedQueue.offer[1] for finishing a span. RealSpan.finish[2]
> > has a synchronized block, RealScopedSpan.finish[3] doesn't. If a
> > virtual thread using RealScopedSpan is next line for the lock, but all
> > carriers are currently occupied by pinned VTs in RealSpan.finish, the
> > application will deadlock:
> >
> > https://gist.github.com/DanielThomas/dddd850f7e491cac3a2dd734978f4267
> >
> > Looking forward to the locking improvements!
> >
>
> Yes, if a j.u.concurrent lock is sometimes acquired by threads holding a
> monitor and at other times by threads that aren't holding a monitor then
> deadlock is possible when all carriers are pinned and the selected
> successor is unmounted. Have you, or your team, tried the early access
> build [1] with the changes for object monitors yet?
>
> -Alan
>
> [1] https://jdk.java.net/loom/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240626/88a24e92/attachment.htm>