On Mon, 28 Oct 2024 00:43:47 GMT, David Holmes <dhol...@openjdk.org> wrote:
>>> I'm struggling to understand how a thread can already be on this list? >>> >> With the removal of the _Responsible thread, it's less likely but it could >> still happen. One case is when the virtual thread acquires the monitor after >> adding itself to `_cxq` in `ObjectMonitor::VThreadMonitorEnter`. The owner >> could have released the monitor in `ExitEpilog` and already added the >> virtual thread to the waiting list. The virtual thread will continue running >> and may face contention on a different monitor. When the owner of this >> latter monitor picks the virtual thread as the successor it might still find >> it on the waiting list (unblocker thread did not run yet). The same case can >> happen in `ObjectMonitor::resume_operation` when acquiring the monitor after >> clearing successor. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245776
