On Thu, 24 Oct 2024 08:26:12 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have: >> >> RUNNING -> BLOCKING -> BLOCKED >> BLOCKED -> UNBLOCKING -> RUNNABLE >> >> I'm just trying to get a better sense of what we can infer if we see these >> "transition" states. > > We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that > accurately describes the state at this point. It's not mounted but may be > scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", > it's the equivalent of OS thread queued to the OS scheduler. So I think the > name is good and would prefer not change it. Okay but I'm finding it hard to see these names and easily interpret what some of them mean. I think there is a difference between UNBLOCKED and UNPARKED, because as an API once you are unparked that is it - operation over. But for UNBLOCKED you are still in a transitional state and it is not yet determined what you will actually end up doing i.e. get the monitor or block again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815761305
