rfc@edk2.groups.io

Home Messages Hashtags

Messages

Between

and

Re: MemoryFence()

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

By Laszlo Ersek · #521 ·

Re: MemoryFence()

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

By Paolo Bonzini <pbonzini@...> · #520 ·

Re: MemoryFence()

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

By Ni, Ray · #519 ·

Re: MemoryFence()

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

By Laszlo Ersek · #518 ·

Re: MemoryFence()

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

By Paolo Bonzini <pbonzini@...> · #517 ·

Re: MemoryFence()

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

By Andrew Fish <afish@...> · #516 ·

Re: MemoryFence()

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

By Ni, Ray · #515 ·

Re: MemoryFence()

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

By Ni, Ray · #514 ·

Re: MemoryFence()

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

By Paolo Bonzini <pbonzini@...> · #513 ·

Re: MemoryFence()

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

By Ni, Ray · #512 ·

Re: MemoryFence()

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

By Andrew Fish <afish@...> · #511 ·

Re: MemoryFence()

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

By Andrew Fish <afish@...> · #510 ·

Re: MemoryFence()

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

By Paolo Bonzini <pbonzini@...> · #509 ·

Re: MemoryFence()

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

By Andrew Fish <afish@...> · #508 ·

Re: MemoryFence()

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

By Laszlo Ersek · #507 ·

Re: MemoryFence()

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

By Paolo Bonzini <pbonzini@...> · #506 ·

Re: MemoryFence()

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

By Laszlo Ersek · #505 ·

Re: MemoryFence()

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

By Ni, Ray · #504 ·

Re: MemoryFence()

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

By Paolo Bonzini <pbonzini@...> · #503 ·

Re: MemoryFence()

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

By Ard Biesheuvel <ardb@...> · #502 ·

281 - 300 of 800

Home Hashtags About Features Pricing Updates Terms Help Twitter