By: NoSpammer (no.delete@this.spam.com), July 14, 2015 2:02 pm
Room: Moderated Discussions
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. That's very true on x86 when reading on one core what the other has written. Usually it's the first example in all intel manuals. Ok, there are some gotchas with streaming stores, flushes, split unaligned writes and possibly string instructions, but otherwise it works as advertised. You just need to make sure your compiler doesn't move other reads around volatile reads (which MSVC seems not to).
> 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. That's very true on x86 when reading on one core what the other has written. Usually it's the first example in all intel manuals. Ok, there are some gotchas with streaming stores, flushes, split unaligned writes and possibly string instructions, but otherwise it works as advertised. You just need to make sure your compiler doesn't move other reads around volatile reads (which MSVC seems not to).