RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
Quan Anh Mai
qamai at openjdk.org
Tue Nov 5 14:07:12 UTC 2024
On Mon, 4 Nov 2024 19:08:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
>> `checkValidStateRaw` synchronizes with `justClose` using handshakes so an opaque or higher load is only needed in `sharedSessionAlreadyClosed`. A `getOpaque` would probably be adequate. But I believe there is no formal restriction preventing the load from being hoisted out of the loop, so I decided to go for the strongest ordering in this exception-throwing case.
>
> Doesn't using `setOpaque` mean that another thread may see the update to `state` before the update to `acquireCount`? i.e. the scope of a memory segment may appear closed, but the segment would still be passable to a downcall?
@JornVernee The acquire property of the `acquireCount` compare exchange prevents the `state` store from floating above it. But following @minborg suggestion I changed it to a volatile store.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1829408406
More information about the core-libs-dev
mailing list