anon (anon.delete@this.anon.com) on July 14, 2015 9:37 pm wrote:
> NoSpammer (no.delete@this.spam.com) on July 14, 2015 2:02 pm wrote:
> > Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on July 13, 2015 4:50 pm wrote:
> > > NoSpammer (no.delete@this.spam.com) on July 13, 2015 12:34 pm wrote:
> > > > With x86 a volatile variable is at least up to date monotonically with respect to what you've seen
> > > > so far. That's actually good enough and it's excellent for producer-consumer type of stuff.
> > >
> > > That's not even true on x86. Loads may be lifted before stores
> > > and so you may read an incorrect or "impossible" value.
> >
> > Let me rephrase it: suppose you have a volatile location
> > you observe, it's possible that you see all changes
> > prior to a volatile change, but not yet the volatile change, it's also possible that you see all changes
> > and the volatile changed, but it's not possible to see a volatile changed but then in later code not see
> > prior changes.
>
> At it's most general, looking at system-wide state, this is untrue. Forwarding from the store
> queue means that a write can be seen (from one CPU) and then not be seen (from another).
>

It seems, in explanation above NoSpammer was taking about situation in which all changes of interest are done by one (producer) CPU and observed by another one (consumer) CPU. For such situation x86 ordering guarantees are not just strong enough, but stronger than necessary. I think, they are also sufficient for slightly more complicated case where consumer acknowledges the consumption of the item to the producer. With the help of interlocked primitives it can be extended to a case of single producer feeding multiple consumers (probably better described as multiple consumers eating from a single consumer) and you will still need no memory barriers except those implied in x86 interlocked operations and still will not be impacted at by store forwarding violation of sequential consistency.