I see. Yeah, this ordering does seem like easier to work with. So I don't quite see what would make "memory_order_seq_cst" harder? From the spec

Well for the IoLib that is + ~100 clock cycles for every MMIO read/write so that makes me a little nervous. Thanks, Andrew Fish

I'd say it is because we are reasoning about how accesses to the data are ordered, not about the data itself.

( Slightly off-topic, but I wonder why this approach (code annotations) has proved more effective / successful, with atomics, than annotating data. Usually it's recommended to put emphasis on data

I disagree, as long as we talk about CPU synchronization through variables that live in RAM. "volatile" has a use case, yes, but not for this purpose. The Linux document Paolo referenced earlier

Well, that could certainly be a next step, but I intentionally left it out of my proposal to Laszlo. The reason for that is that the fences are already enough to wean the edk2 codebase from volatile

Yes, this points too much toward C++. But Paolo's find: #define _Compiler_barrier() \ _STL_DISABLE_DEPRECATED_WARNING _ReadWriteBarrier() \ _STL_RESTORE_DEPRECATED_WARNING suggests we should

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

“inline assembly is not supported on the ARM and x64 processors. “ [1]. Kind of looks like MSVC replaced inline assembly with intrinsics [2]. Looks like _ReadBarrier, _ReadWriteBarrier [3] are

In theory, atomic_thread_fence (and in this case, more specifically, atomic_signal_fence) is available also on C11. But if it is possible to assume that _RWB is present on Microsoft toolchains (even

[*] Doesn't look too specific: https://docs.microsoft.com/en-us/cpp/assembler/inline/optimizing-inline-assembly?view=msvc-160 I've found this article very relevant:

Generally, yes. But I already mentioned non-cache coherent DMA devices, and we also have some ARM platforms that use non-shareable mappings for SRAM, which is used as temporary PEI memory in

This seems consistent with the fact that Paolo recommended variants of "dmb ish" for all the memory (not compiler) fences -- I guess we don't care about actual RAM content as long as all CPUs and

<snip> I don't think the message passing paradigm is 100% accurate but it is very close. You should realize that a modern system is a network of CPUs, caches, DRAM controllers and other bus masters,

I am sorry for redirecting to the C++11 share memory model. It has nothing to do with EDK2 here because EDK2 is C based. It's not that TRUE today. If you look into UefiCpuPkg, MpInitLib,

Looks like we are heading for a crash too. So good thing we are thinking about it. The good news is EFI does not have threads and the PI MpServices protocol is indirectly messaging based as you wait

rant warning Thanks. I think what happened here is a catastrophic impedance mismatch. The underlying, physical architecture is a message-passing one. Yet the mental abstraction that is built atop,

Got it, it's a very good question. All edk2 porting targets should naturally align all types not larger than pointers. I can only think of old m68k that had 2-byte aligned 32-bit pointers. Another

Laszlo, Clang treats unaligned pointers as undefined behavior (UB). I’m not sure if this is due to C11? What I know is clang choses to NOT optimize away UB from alignment errors, but if you run the

Ray, In C calling out to assembly is also a barrier/fence operation from the compilers point of view. Actually calling an indirect procedure call (gBS->*, Protoco->*) is also a barrier. The compiler