Re: MemoryFence()

Ni, Ray

Maybe that explains why the MemoryFence was implemented so confidently.
I trust Mike:)

In UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c, the LibWaitForSemaphore, LibReleaseSemaphore are coded without the read write barrier.
But the AcquireSpinLockOrFail and ReleaseSpinLock in MdePkg/Library/BaseSynchronizationLib/SynchronizationMsc.c contain read write barrier.
Is the former implementation wrong because without the barrier the cmpxchg can happen earlier or later chosen by the compiler?

Does volatile keyword help here?

发件人: Paolo Bonzini <pbonzini@...>
发送时间: Friday, February 5, 2021 11:42:36 PM
收件人: Ard Biesheuvel <ardb@...>
抄送: Laszlo Ersek <lersek@...>; Ni, Ray <>; Andrew Fish <afish@...>; edk2 RFC list <>; Kinney, Michael D <michael.d.kinney@...>; Leif Lindholm (Nuvia address) <leif@...>; Dong, Eric <eric.dong@...>; Liming Gao (Byosoft address) <gaoliming@...>; Ankur Arora <ankur.a.arora@...>
主题: Re: MemoryFence()

On 05/02/21 16:39, Ard Biesheuvel wrote:
On Fri, 5 Feb 2021 at 16:38, Paolo Bonzini <pbonzini@...> wrote:

On 05/02/21 16:34, Laszlo Ersek wrote:
And your code is wrong because the*original*, namely the MSFT
implementation of MemoryFence() in edk2, is bugged:

* MdePkg/Library/BaseLib/X86MemoryFence.c:

Used to serialize load and store operations.

All loads and stores that proceed calls to this function are guaranteed to be
globally visible when this function returns.

MemoryFence (
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.
We rely heavily on LTO for both Visual Studio and GNU/Clang toolchains.
Oops... Well, it *was* okay at the time MemoryFence() was first
implemented. :(


Join to automatically receive all group messages.