On Mon, 30 Sep 2024 17:03:59 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
> In this case there is no classic release/acquire. Instead, we rely on other > properties: Relying on data-dependency is making assumptions about what the underlying hardware memory models actually do, and is something we should generally avoid in shared code. In the abstract/general sense without a matching explicit acquire action, nothing guarantees you will see writes prior to a release-store. If we are going to rely on data-dependency then it should be clearly documented. See discussion/definitions in src/hotspot/share/runtime/orderAccess.hpp > FWIW, a full fence is just a release+acquire on the executing thread. It has > no effect on other threads. A full fence is more than just release+acquire as it also implies a storeLoad barrier. A full fence should ensure consistent ordering/visibility across all threads (store barriers on sparc, mfence (or equivalent) on x86, DMB on ARM, sync on PPC). At least that is the expected semantics for hotspot. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21160#discussion_r1782182531