On Mon, 28 Oct 2024 22:02:02 GMT, Patricio Chilano Mateo <pchilanom...@openjdk.org> wrote:
>> 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() | | Thanks for that detailed explanation. It is a bit disconcerting that Thread C could leave a trace on monitors it acquired and released in the distant past. But that is an effect of waking the successor after releasing the monitor (which is generally a good thing for performance). We could potentially re-check the successor (which Thread C will clear) before doing the actual unpark (and set_onWaitingList) but that would just narrow the race window not close it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823394886
