RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning
Patricio Chilano Mateo
pchilanomate at openjdk.org
Wed Nov 6 17:40:06 UTC 2024
On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Hmmmm ... I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.
>
> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.
Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail:
| ThreadA | ThreadB | ThreadC |
| --------------------------------------| --------------------------------------| ---------------------------------------------|
| | |VThreadMonitorEnter:fails to acquire monitorB |
| | | VThreadMonitorEnter:adds to B's _cxq |
| | ExitEpilog:picks ThreadC as succesor | |
| | ExitEpilog:releases monitorB | |
| | | VThreadMonitorEnter:acquires monitorB |
| | | VThreadMonitorEnter:removes from B's _cxq |
| | | continues execution in Java |
| | |VThreadMonitorEnter:fails to acquire monitorA |
| | | VThreadMonitorEnter:adds to A's _cxq |
| ExitEpilog:picks ThreadC as succesor | | |
| ExitEpilog:releases monitorA | | |
| ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList() | |
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819829472
More information about the core-libs-dev
mailing list