On Mon, 6 May 2024 21:42:10 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> I don't see how that helps. Access to the field is not protected. > > I guess there could be a race if one thread is destroying this monitor while > another is trying to use it. Thus a thread could be doing something like a > RawMonitorEnter in the middle of (or after) the monitor being destroyed. > Fixing that would require holding dbgRawMonitor during RawMonitorEnter, and > that would cause deadlocks all over the place. Also, this same potential > issue exists already, but doesn't seem to ever arise. It seems we only call > debugMonitorDestroy for cmdQueueLock. Not sure why that is. FWIW Deleting monitors is a tricky business and needs to be done with great care. You have to ensure all threads using the monitor are completely done with it. Simply locking it first to check it is "unused" is not sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19044#discussion_r1596015404
