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.

I think it's okay-ish (it works as long as you don't do link-time optimization, but it's less efficient than a compiler intrinsic) because X86MemoryFence.c is a separate file. Paolo

That's because your CompilerFence() function is not correct. You did: which is wrong. It enforces a C-language sequence point, but it does not implement a compiler barrier. And your code is wrong

A compiler barrier (in case that's sufficient), or even a memory fence -- seems more appropriate for inter-CPU synchronization -- which I think should be implemented to automatically force a compiler

Ah, thanks; also good example where a CompilerFence() would be justified. Laszlo

This should be #define CompilerFence _ReadWriteBarrier Paolo