<div dir="ltr"><div>MongoDB Java driver uses synchronized blocks/methods in some places. When reading "JEP 425: Virtual Threads", the team saw that<br></div><div><br>> There is no need to replace synchronized blocks and methods that are used infrequently (e.g., only performed at startup) *or that guard in-memory operations*.<br><br>Our understanding is that the part of the above sentence talking about blocks that guard in-memory operations implies that an attempt to enter a synchronized block (an attempt to lock the monitor) works similarly to an attempt to acquire a ReentrantLock: it allows the virtual thread to be unmounted and another virtual thread to be mounted on the same carrier if the carrier would have been blocked otherwise, because of the monitor being locked by another thread. This understanding is consistent with the list of scenarios from JEP 425 that describe when a virtual thread is pinned (note how #1 talks specifically about executing code inside a synchronized method and does not talk about attempting to lock the monitor):<br><br>> 1. When it executes code inside a synchronized block or method, or<br>> 2. When it executes a native method or a foreign function.<br><br>When experimenting, we noticed that it is possible to write an application that uses the driver and hangs as a result of carriers being "consumed" by virtual threads pinned to them not because those virtual threads execute code inside a synchronized method, but because they are attempting to lock a monitor in order to start executing a synchronized method, which is being executed by another thread. We also confirmed with a simple code that does not use the driver, that an attempt to lock a monitor is enough to pin a virtual thread. That is, a virtual thread is pinned to its carrier as soon as it attempts to enter a synchronized block, it stays pinned until the monitor is released by another thread, and then continues to be pinned while it executed the code inside the synchronized block (this last part is what the JEP 425 informs about).<br><br>Could you please help us to understand whether this is<br>- a peculiarity of the early access builds (reproduced on OpenJDK Runtime Environment (build 19-ea+27-2074)), and the released JDK 19 will not behave this way;<br>- an intended behavior that may be worth specifying in the JEP description by updating the first scenario describing when a virtual thread may be pinned;<br>- something else?<br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Regards,<div><a href="https://urldefense.com/v3/__https://www.mongodb.com__;!!ACWV5N9M2RV99hQ!JXNCnFeaorvpA-dClT3tayS0wT46ARaJLSupgQW64n4uyGCAwnVG4AWo2Hwpyu0aAdetvCLwVtjEI06V0Pv12FtXH6q99JE$" target="_blank"><img width="200" height="50" src="https://ci3.googleusercontent.com/mail-sig/AIorK4xUBfDkAoDAl6zg2cU8iQDfyZQDxlztRyMWxxW-EMQWrCt85NaLzp7SdNEYwaLU8N9zz4x9z8Q"></a></div><div><p style="margin:10px 0px 0px 5pt;padding:0px"><code style="font-family:SFMono-Medium,"SF Mono","Segoe UI Mono","Roboto Mono","Ubuntu Mono",Menlo,Courier,monospace"><strong>{</strong> name     : "<a href="https://urldefense.com/v3/__https://www.kovalenko.link/__;!!ACWV5N9M2RV99hQ!JXNCnFeaorvpA-dClT3tayS0wT46ARaJLSupgQW64n4uyGCAwnVG4AWo2Hwpyu0aAdetvCLwVtjEI06V0Pv12FtXr_qXxDw$" target="_blank">Valentin Kovalenko</a>",<br>  title    : "<span style="color:rgb(23,43,77)">Senior </span><a href="https://urldefense.com/v3/__https://www.mongodb.com/docs/drivers/java-drivers/__;!!ACWV5N9M2RV99hQ!JXNCnFeaorvpA-dClT3tayS0wT46ARaJLSupgQW64n4uyGCAwnVG4AWo2Hwpyu0aAdetvCLwVtjEI06V0Pv12FtXaHM0GYE$" target="_blank">Java Driver</a><span style="color:rgb(23,43,77)"> Engineer</span>",<br>  location : "<span style="color:rgb(23,43,77)">Calgary, Canada</span>" <strong>}<br></strong></code></p></div></div></div></div></div>