On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes <dhol...@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
