We're getting a little confused on the terminology. That's a compiler barrier, as it prevents the compiler from reordering certain instructions beyond it (I don't think relaxed prevents any reordering, but release and acquire do.) I know you understand this stuff given your background, I just want to clarify the terminology for the sake of the discussion.
The original post and article discuss real memory barriers like mfence. These prevent the CPU from reordering loads and stores. Which should be unnecessary for SPSC queues on x86 because it gives strong enough guarantees about reordering, in this case, without that. On Mon, Mar 19, 2018, 1:19 AM Avi Kivity <[email protected]> wrote: > The release write is a memory barrier. It's not an SFENCE or another fancy > instruction, but it is a memory barrier from the application writer's point > of view. > > > The C++ code > > > x.store(5, std::memory_order_relaxed) > > has two effects on x86: > > 1. generate a write to x that is a single instruction (e.g. mov $5, x) > 2. prevent preceding writes from being reordered by the compiler (they > are implicitly ordered by the processor on x86). > > > > On 03/18/2018 08:16 PM, Dan Eloff wrote: > > You don't need memory barriers to implement an SPSC queue for x86. You can > do a relaxed store to the queue followed by a release write to > producer_idx. As long as consumer begins with an acquire load from > producer_idx it is guaranteed to see all stores to the queue memory before > producer_idx, according to the happens before ordering. There are no memory > barriers on x86 for acquire/release semantics. > > The release/acquire semantics have no meaning when used with different > memory locations, but if used on producer_idx when synchronizing the > consumer, and consumer_idx when synchronizing the producer, it should work. > > > > On Thu, Feb 15, 2018 at 8:29 AM, Avi Kivity <[email protected]> wrote: > >> Ever see mfence (aka full memory barrier, or std::memory_order_seq_cst) >> taking the top row in a profile? Here's the complicated story of how we >> took it down: >> >> >> https://www.scylladb.com/2018/02/15/memory-barriers-seastar-linux/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
