Re: MemoryFence()


Ni, Ray
 


The shared memory model is a *wreck*, given how the hardware operates
underneath.
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.

The good news is EFI does not have threads and the PI MpServices protocol is indirectly messaging based as you wait for a
function to return or an event. Like C it can be abused since the memory is shared.
It's not that TRUE today.
If you look into UefiCpuPkg, MpInitLib, RegisterCpuFeaturesLib, PiSmmCpu, these modules heavily depend on the sync primitives.
I don't like the today's situation that:
1. no semaphore standard library
2. no mutex standard library (there is a BaseSynchronization library that provides spinlock, cmpxchg, lock inc/dec primitives. I prefer a mutex lib over this BaseSync lib.)
2. directly using volatile over SPIN_BLOCK
3. using volatile which can be avoided as concluded by the discussion.

If with the above wheels invented, even with MP service, one can write a complex long-run daemon procedure and sync with BSP properly.


Ironically the complexity of writing thread safe code in C and the fact that back in the day a big pool of the x86 firmware
writers were hardware folks who wrote in x86 assembler is one of the reasons EFI ended up with. No threads an a
cooperative event model…..

Thanks,

Andrew Fish

Laszlo

Join rfc@edk2.groups.io to automatically receive all group messages.