On Thu, 22 Jan 2026 18:35:51 GMT, Patricio Chilano Mateo <[email protected]> wrote:
>> 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. Thanks @pchilano, I was not aware of that property of agents. With that in mind, it makes sense to check the state in the condition. Modified the code accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2720303739
