RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v3]
David Holmes
dholmes at openjdk.org
Thu Oct 24 05:58:18 UTC 2024
On Wed, 23 Oct 2024 17:32:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 111:
>>
>>> 109: * BLOCKING -> BLOCKED // blocked on monitor enter
>>> 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue
>>> 111: * UNBLOCKED -> RUNNING // continue execution after blocked on monitor enter
>>
>> Presumably this one means it acquired the monitor?
>
> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.
So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
RUNNING -> BLOCKING -> BLOCKED
BLOCKED -> UNBLOCKING -> RUNNABLE
I'm just trying to get a better sense of what we can infer if we see these "transition" states.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283
More information about the serviceability-dev
mailing list