Sorry, I understand now. Yes, you're absolutely correct, the mfence (or similar) is required there.
x86 makes strong guarantees about instruction reordering - Loads are *not * reordered with other loads. - Stores are *not * reordered with other stores. - Stores are *not * reordered with older loads. - In a multiprocessor system, memory ordering *obeys causality* (memory ordering respects transitive visibility). - In a multiprocessor system, stores to the same location have a *total order*. - In a multiprocessor system, locked instructions have a *total order*. - Loads and stores are *not* reordered with locked instructions. But that comes with a very important non-guarantee: - Loads may be reordered with older stores to different locations Because producer_idx and consumer_is_sleeping are different variables, the load to consumer_is_sleeping may be reordred by the processor and execute before the store to producer_idx, which could cause the consumer to sleep with work available, and not be woken for it. On Wed, Mar 21, 2018 at 10:44 AM, Avi Kivity <[email protected]> wrote: > The mfence was not in the SPSC queue implementation, but in the code that > allows wakes a potentially sleeping MPSC consumer. > > > producer_idx.store(..., memory_order_release) > > if (consumer_is_sleeping) wake_it_up() > > > an mfence (or a clever trick) is required between these two lines. > > On 03/19/2018 04:41 PM, Dan Eloff wrote: > > 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. > > > -- 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.
