HI guys! Re
> 2. prevent preceding writes from being reordered by the compiler (they are implicitly ordered by the processor on x86). I have had a quite interesting chat with Jeff Preshing (http://preshing.com/) about relaxed guarantees and he pointed me this one to help on it: https://www.decadent.org.uk/pipermail/cpp-threads/2008-December/001946.html And quoting himself: > > 1. > > As I wrote above, "each atomic var has its own modification order"... > once a value in that modification is seen, older ones cannot be seen again > Segnala questo messaggio inviato da Jeff PreshingElimina questo > messaggio inviato da Jeff Preshing > 12 feb 2017 > 2. [image: Jeff Preshing] > <https://twitter.com/preshing> > > Note this guarantee has nothing to do with acquire/release... it's a > separate guarantee, that each atomic var being consistent with its own > modification order > > Il giorno lunedì 19 marzo 2018 09:19:08 UTC+1, Avi Kivity ha scritto: > > 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 <a...@scylladb.com > <javascript:>> 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 mechanical-sympathy+unsubscr...@googlegroups.com <javascript:>. >> 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 mechanical-sympathy+unsubscr...@googlegroups.com <javascript:>. > 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 mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
