3 ms·
As a minor note, LDAR and STLR are poorly named and are documented as providing multicopy atomicity in addition to acquire-release semantics and are the recomme
by tntn 7y ago
As a minor note, LDAR and STLR are poorly named and are documented as providing multicopy atomicity in addition to acquire-release semantics and are the recommended way to implement C11 SeqCst.
Some of the below is almost certainly incorrect, apologies in advance.
Your example is more or less the Independent Read Independent Write (IRIW+syncs) litmus test. The short version is you don't need to flush any caches to get IRIW to always obey sequential consistency.
Originally, ARMv8 was non-multicopy atomic, but AFAIK there was never any non-multicopy atomic implementation, and a revised spec requires multicopy atomicity. This matters in terms of thinking about how sequential consistency for IRIW is implemented, but it works either way.
The core idea is that the DMB ISH ensures that the value that the first reads in threads c and d receive are visible to all threads. With multicopy atomicity this is free - e.g. if Thread C reads true from X, then all other threads will also read true.
(-> below indicates a sequenced before relationship)
So you get
Thread C: read X as true -> dmb ish -> read Y as false
Thread D: read Y as true -> dmb ish -> read X as false
However, you get some extra edges. If either thread reads X as false, then X as true is not visible to any thread. So you get
(Thread C reads y as false) -> (Thread D reads Y as true)
(Thread D reads x as false) -> (thread c reads x as true)
These are enough to produce a cycle that forbids the z=0 case.
Essentially, threads A and B have to make sure that once any thread sees its write, all threads see its write. (Or alternatively the dmb ish on thread C and D have to ensure that future memory accesses from that thread don't proceed until the prior read is consistent to all cores).
- dragontamer 7y agoThanks for the in-depth answer! > Essentially, threads A and B have to make sure that once any thread sees its write, all threads see its write Gotcha. So that's where cache snooping comes in and why that's sufficient to handle the case. I think I see it now. Again, thanks for breaking it down for me. So it appears the only thing necessary is for the DMB ISH to ensure that all cache-snoop messages are "processed" before proceeding.