<div dir="ltr"><div>Hi Alan,<br><br>Thank you for the clarification.<br><br>> The text you quote from the JEP is correct and I think you are just asking that it be expanded to cover this case. <br><br>Right. If the behavior is intended, then it may be worth clarifying the behavior in the JEP, especially because I was not the only one even in out small team who was misled by the current JEP wording. To me the wording<br><br>> a virtual thread cannot be unmounted when it is blocked on monitor enter<br><br>implies different and more severe consequences than the current one<br><br>> a virtual thread cannot be unmounted ... When it executes code inside a synchronized block or method<br></div><div><br></div><div>Regards,<br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><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     : "Valentin Kovalenko",<br>  title    : "<span style="color:rgb(23,43,77)">Senior </span>Java Driver<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><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 23, 2022 at 2:26 AM 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:1px solid rgb(204,204,204);padding-left:1ex">On 22/06/2022 23:16, Valentin Kavalenka wrote:<br>
> MongoDB Java driver uses synchronized blocks/methods in some places. <br>
> When reading "JEP 425: Virtual Threads", the team saw that<br>
><br>
> > There is no need to replace synchronized blocks and methods that are <br>
> used infrequently (e.g., only performed at startup) *or that guard <br>
> in-memory operations*.<br>
><br>
> Our understanding is that the part of the above sentence talking about <br>
> blocks that guard in-memory operations implies that an attempt to <br>
> enter a synchronized block (an attempt to lock the monitor) works <br>
> similarly to an attempt to acquire a ReentrantLock: it allows the <br>
> virtual thread to be unmounted and another virtual thread to be <br>
> mounted on the same carrier if the carrier would have been blocked <br>
> otherwise, because of the monitor being locked by another thread. This <br>
> understanding is consistent with the list of scenarios from JEP 425 <br>
> that describe when a virtual thread is pinned (note how #1 talks <br>
> specifically about executing code inside a synchronized method and <br>
> 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 <br>
> application that uses the driver and hangs as a result of carriers <br>
> being "consumed" by virtual threads pinned to them not because those <br>
> virtual threads execute code inside a synchronized method, but because <br>
> they are attempting to lock a monitor in order to start executing a <br>
> synchronized method, which is being executed by another thread. We <br>
> also confirmed with a simple code that does not use the driver, that <br>
> an attempt to lock a monitor is enough to pin a virtual thread. That <br>
> is, a virtual thread is pinned to its carrier as soon as it attempts <br>
> to enter a synchronized block, it stays pinned until the monitor is <br>
> released by another thread, and then continues to be pinned while it <br>
> executed the code inside the synchronized block (this last part is <br>
> 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 <br>
> Runtime Environment (build 19-ea+27-2074)), and the released JDK 19 <br>
> will not behave this way;<br>
> - an intended behavior that may be worth specifying in the JEP <br>
> description by updating the first scenario describing when a virtual <br>
> thread may be pinned;<br>
> - something else?<br>
><br>
<br>
This is expected behavior. A current limitation is that a virtual thread <br>
cannot be unmounted when it is blocked on monitor enter (as the monitor <br>
is owned by another thread). The text you quote from the JEP is correct <br>
and I think you are just asking that it be expanded to cover this case. <br>
I don't know anything about the MongoDB driver but it might be the <br>
locking around the socket I/O needs addition rather than all monitors, <br>
meaning you may not have to replace the monitors used to guard data <br>
structures when you aren't doing I/O in the locked regions.<br>
<br>
-Alan<br>
<br>
<br>
</blockquote></div>