On 2021-02-09 5:00 a.m., Paolo Bonzini wrote:
On 08/02/21 21:44, Ankur Arora wrote:
Well, that could certainly be a next step, but I intentionally left it out of my proposal to Laszlo.
Since the first two are of unequal power -- volatile for specific
accesses and the compiler fence being a general barrier across which
the compiler does not optimize memory accesses I think we should have
both instead of volatile or compiler fence.
However, instead of volatile, how about read_once(), write_once()
primitives? These, respectively ensure that the compiler emits a
single load or a store and does not combine or mutilate the load/store
in any way.
The reason for that is that the fences are already enough to wean the edk2 codebase from volatile declarations and pointers, and that is the big paradigm change---annotating code rather than data.
Once you've done that switch I would certainly agree with (basically) an edk2 flavor of C11-like atomic primitives:
- at the very least, AtomicLoadRelaxed and AtomicStoreRelaxed corresponding to Linux's READ_ONCE/WRITE_ONCE
- and if it is possible to implement them easily on MSVC, AtomicLoadAcquire and AtomicStoreRelease
However, these changes do not have to be done in a single step. Starting with the rationalization of memory fences makes sense because, in addition to enabling the annotation of code rather than data, it is essentially a bugfix.
I see. Yeah, this ordering does seem like easier to
As an aside, I always stay away from the "memory_order_seq_cst" loads and stores. Those are much more tricky than what their name suggests, and their use cases are much better served by something like
AtomicStoreRelaxed(&a, 1); // atomic_store(mo_relaxed)
MemoryFence(); // atomic_thread_fence(mo_seq_cst)
y = AtomicLoadRelaxed(&b); // atomic_load(mo_relaxed)
So I don't quite see what would make "memory_order_seq_cst" harder?
From the spec (https://en.cppreference.com/w/cpp/atomic/memory_order#Sequentially-consistent_ordering
"Atomic operations tagged memory_order_seq_cst not only order
memory the same way as release/acquire ordering (everything
that happened-before a store in one thread becomes a visible
side effect in the thread that did a load), but also establish
a single total modification order of all atomic operations
that are so tagged."
Is the total modification order the problem?