RFR: 8325937: runtime/handshake/HandshakeDirectTest.java causes "monitor end should be strictly below the frame pointer" assertion failure on AArch64 [v2]
Andrew Haley
aph at openjdk.org
Fri Oct 4 09:08:37 UTC 2024
On Fri, 4 Oct 2024 08:17:33 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:
> > Yes, that's right. Code in critical sections isn't racy, by definition.
>
> I suppose it depends on what we mean by racy. The critical sections are atomic if synchronized appropriately, but with only acquire/release semantics (what glibc seemingly does in practice), they might for example be observed to happen in inconsistent orders.
Sure, that's fair. I should have perhaps been more explicit about "racy," by which I meant the term defined in ISO C++, [intro.races] "Data races". And the lack of data races doesn't imply that every thread sees writes in the same order, as you say. Relaxed atomics don't contribute to data races and neither do the examples you showed, although both can be reordered.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21295#issuecomment-2393226133
More information about the hotspot-runtime-dev
mailing list