回复：Real-world Pinning/ReentrantLock deadlock

[何品(虎鸣)]

is it possible to make the `unparker` plugable ?
------------------------------------------------------------------
发件人：Danny Thomas <dannyt at netflix.com>
发送时间：2024年6月26日(星期三) 13:37
收件人：Alan Bateman<Alan.Bateman at oracle.com>
抄　送："loom-dev"<loom-dev at openjdk.org>
主　题：Re: Real-world Pinning/ReentrantLock deadlock
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 <mailto: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 <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/ <https://jdk.java.net/loom/ >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240626/aef23cf1/attachment-0001.htm>