<div dir="auto">Working on looking at the scheduler, poller and locking changes as we speak. </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 25 Jun 2024 at 4:21 PM, Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
<br>
On 25/06/2024 02:13, Danny Thomas wrote:<br>
> Hi folks,<br>
><br>
> We ran into a real-world deadlock with virtual threads and Micrometer, <br>
> Brave/Zipkin. In short, there are two paths to <br>
> CountBoundedQueue.offer[1] for finishing a span. RealSpan.finish[2] <br>
> has a synchronized block, RealScopedSpan.finish[3] doesn't. If a <br>
> virtual thread using RealScopedSpan is next line for the lock, but all <br>
> carriers are currently occupied by pinned VTs in RealSpan.finish, the <br>
> application will deadlock:<br>
><br>
> <a href="https://gist.github.com/DanielThomas/dddd850f7e491cac3a2dd734978f4267" rel="noreferrer" target="_blank">https://gist.github.com/DanielThomas/dddd850f7e491cac3a2dd734978f4267</a><br>
><br>
> Looking forward to the locking improvements!<br>
><br>
<br>
Yes, if a j.u.concurrent lock is sometimes acquired by threads holding a <br>
monitor and at other times by threads that aren't holding a monitor then <br>
deadlock is possible when all carriers are pinned and the selected <br>
successor is unmounted. Have you, or your team, tried the early access <br>
build [1] with the changes for object monitors yet?<br>
<br>
-Alan<br>
<br>
[1] <a href="https://jdk.java.net/loom/" rel="noreferrer" target="_blank">https://jdk.java.net/loom/</a><br>
</blockquote></div></div>