On Wed, 5 Jan 2022 18:24:39 GMT, Paul Sandoz <psan...@openjdk.org> wrote:
>> I'll change use of `owner`. It's not really possible to write >> checkValidStateSlow in terms of checkValidState, because the latter does a >> plain read of the state, whereas the former does a volatile read. Reusing >> one from the other would result in two reads (a plain and a volatile). > > Ok. My thought was that since this is slow two reads do not matter, but i did > not reason fully about the concurrent implications (if the fast alive check > returns false, the slow alive check can still return true so that seems good, > if the fast check returns true i was presume the slow alive check would also > be true, given the way state changes monotonically?) If we're ok with a redundant plain read, then I don't think there are issues. You just do two reads, and the latter (the volatile one) is the one that counts. I don't think we can rely much on dependencies between what the plain read and what the volatile read will see. The state is updated in both direction (for shared segments) e.g. we can go from ALIVE to CLOSING then back to ALIVE. Or we could go from ALIVE to CLOSING to CLOSE. That said, I guess my main reservation for writing one routine on top of the other is that we really want checkValidState to be only used in critical hot paths. It has a non-volatile semantics and an exception handling which only really makes sense when combined with ScopedMemoryAccess - for this reason, using it as an internal building primitive didn't seem to me as a great idea. ------------- PR: https://git.openjdk.java.net/jdk18/pull/82
