My question was unclearly asked, sorry. Let's say we have a UINT32 at an address that's not a multiple of 4, but a multiple of 2. A pointer to that UINT32 is "acceptably aligned" on x86, but not

To expand: it is an assumption on the implementation of the C compiler; it admittedly goes beyond the C standard but it is a reasonable assumption, compilers may *merge* loads and stores but have no

Wow! Thank you Paolo for explaining everything! I read a bit about c memory model. https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync Do you have any documentation that can explain how the different

This is why I'd like someone else to write the primitives :) - Where is this documented? - Is it architecture-dependent? - Is it alignment-dependent? etc... :) (I'm not challenging your statement

On x86 load-load, load-store and store-store ordering is already guaranteed by the processor. Therefore on x86 the AcquireMemoryFence and ReleaseMemoryFence are just like CompilerFence: they only have

Ray, Yes I was writing a mail when I wrote the bugzilla…. Ray, Function calls are not compiler fences. The compiler just optimized the code way as dead code. For non VC++ we have a real compiler

I saw the proposal of fences in first mail by Laszlo. Please forgive my ignorance. What is asm(“”) in x86? A nop? The how a nop can help as a processor level load store

Andrew, I just read the link you provided. It recommends to use mutex semaphore spin lock over volatile. But the funny thing here is we are talking about how to implement the mutex semaphore spin lock

The proposed ReleaseMemoryFence() should already have that effect. All the proposed fences except CompilerFence() are both compiler optimization barriers and processor barriers.

Without calling _ReadWriteBarrier, is it possible that compiler generates the assembly in the wrong location? I mean the compiler may in-line the LibWaitForSemaphore and call cmpxchg earlier than the

We do link time optimization on VC++ and clang. Thanks, Andrew Fish

Ray, I agree the C definition of volatile is not thread safe. I was doing some research on volatile and I realize the Linux kernel guides recommend against using volatile [1]. I think it has to do

Not as long as it's a pointer or smaller. Paolo

OK I see Linux recommends not using volatile [1], so I think this makes sense to me. It is not that volatile is not useful, but it is not thread safe, so not using volatile encourages people to use

No concern that the store might not be atomic? Thanks Laszlo

Agreed. I would prefer an explicit compiler fence before the "Value = *Sem" assignment and no volatile anywhere, but it is okay. The _ReadWriteBarrier (aka compiler fence) is pointless too; it is

Let's focus on the "down" operations first. At commit c6be6dab9c4b: 789 /** 790 Decrement the semaphore by 1 if it is not zero. 791 792 Performs an atomic decrement operation for

Maybe that explains why the MemoryFence was implemented so confidently. I trust Mike:) In UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c, the LibWaitForSemaphore,

Oops... Well, it *was* okay at the time MemoryFence() was first implemented. :( Paolo

We rely heavily on LTO for both Visual Studio and GNU/Clang toolchains.