On Thu, 22 Jan 2026 10:39:23 GMT, Anton Artemov <[email protected]> wrote:
>> Thinking more, that is not correct either. I don't think there is any way to >> accommodate the event being enabled after notification and still avoid the >> liveness bug. The code as it stands will not post the event if the state is >> TS_ENTER - so we have a "missing event". If it does post the event (per my >> suggestion) then we are back to the problem of the successor potentially >> being suspended. > > Agree, in this case, the ultimate solution would be for a successor thread to > stop being a successor and let any other thread become, if there is any on > the `entry_list`. IIRC it was discussed a few times, and seems to be a rather > complex thing to do. > > I think having no missing event is more important than hitting a successor > being suspended. Moreover, this should be a rather rare case, its probability > would be the probability of someone enabling `monitor_waited` event after > notifying times the probability of having a suspension request around this > point. > > I added the changes you suggested. My thoughts on this case: if the event was disabled when the thread was notified, an agent cannot expect the waited event to be posted. Whether the waiter checks before or after the event is later enabled is inherently racy and an implementation detail. Once the waiter was notified, it could have immediately woke up and observe that the event was not enabled. Similar argument with the other case, event enabled on notification but disabled afterwards. If an agent cares about a particular waited event it would enable it before notification happens and disable it only after receiving the event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2718123607
