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 <ray.ni@...>; Andrew Fish <afish@...>; edk2 RFC list <firstname.lastname@example.org>; 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:Oops... Well, it *was* okay at the time MemoryFence() was firstWe rely heavily on LTO for both Visual Studio and GNU/Clang toolchains.