On 18/09/2020 11:14, Monica Beckwith wrote: > This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1]
It's still wrong, I'm afraid. This is not a full barrier: +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel); it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as well. It might well be that you get the same DMB ISH instruction, but unless you use a StoreLoad barrier here it's theoretically possible for a compiler to reorder accesses so that a processor sees its own stores before other processors do. (And it's confusing for the reader too.) Use: +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst); See here: https://en.cppreference.com/w/cpp/atomic/memory_order memory_order_seq_cst "...plus a single total order exists in which all threads observe all modifications in the same order (see Sequentially-consistent ordering below)" -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
