Pre-pre-RFC: Exploring API design space for volatile atomics

atomic suppresses a bunch of those optimizations also, though. On CPUs where there's a difference, you want ordinary store instructions, not store instructions that lock the memory bus and/or force immediate invalidation of the cache line on sibling cores, right?

In the atomics-based design, you are not using atomics for those normal memory writes (the writes to the actual packet data in the network example). In the "use extra volatile so you don't need atomics" design, you would be using volatile there.

I must be misunderstanding something. Didn't you just say that you had to use atomics for the normal memory writes so that the fence instruction would work? (Possibly not because the hardware wouldn't honor it, but because the compiler wouldn't bother issuing a fence instruction without the atomics?)

You need to have an atomic store after a fence(Release) for it to have any meaning, or an atomic load before a fence(Acquire). You don't need all of the memory operations you care about to be atomic.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.