Describe the Bug
We observed a deadlock with Virtual Threads and Brave/Zipkin. In short, there are two paths to CountBoundedQueue.offer when finishing a span. RealSpan.finish has a synchronized block, where RealScopedSpan.finish does not.
If an unmounted 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
Steps to Reproduce
See https://gist.github.com/DanielThomas/0b099c5f208d7deed8a83bf5fc03179e for a reduced example.
Expected Behaviour
While the monitor pinning limitation will be addressed in future OpenJDK releases, in the meantime there's a good case for switching this class to ReentrantLock to guard the MutableSpan to ensure compatibility with virtual threads.
Describe the Bug
We observed a deadlock with Virtual Threads and Brave/Zipkin. In short, there are two paths to CountBoundedQueue.offer when finishing a span. RealSpan.finish has a synchronized block, where RealScopedSpan.finish does not.
If an unmounted virtual thread using
RealScopedSpanis next line for the lock, but all carriers are currently occupied by pinned VTs inRealSpan.finish, the application will deadlock:https://gist.github.com/DanielThomas/dddd850f7e491cac3a2dd734978f4267
Steps to Reproduce
See https://gist.github.com/DanielThomas/0b099c5f208d7deed8a83bf5fc03179e for a reduced example.
Expected Behaviour
While the monitor pinning limitation will be addressed in future OpenJDK releases, in the meantime there's a good case for switching this class to
ReentrantLockto guard theMutableSpanto ensure compatibility with virtual threads.