Subj : Re: [x86] Reads/Writes To : comp.programming.threads From : David Hopwood Date : Wed Sep 28 2005 03:59 am Cool Guy wrote: > David Schwartz : > >>>I've read (no pun intended) that all writes on x86 are effectively >>>volatile writes. So does that mean that on x86 only 'read' barriers are >>>necessary? >> >> At what level are you talking? Are you assuming that a person is writing >>assembly language code? Or are you talking about to a C programmer? > > At the level of a C programmer I guess. Strictly speaking, this question doesn't have a well-defined answer at the C language level. More pragmatically, for most implementations of C extended with a thread library, barriers are necessary to prevent compiler reordering in programs that attempt to perform accesses that are not synchronized by higher-level mechanisms (mutexes, semaphores, etc.). In general there is no portable way to define such barriers, and no guarantee that this approach can be made to work at all on a given C+threads implementation. If you meant to ask about the assembly/ISA level, then it's not clear what you mean by "volatile writes". "volatile" is defined differently by different languages (in C it does not guarantee anything concrete [*]), and is not defined at all at the ISA level. If you mean something more specific like "ordinary writes to WB memory on x86 have similar memory barrier semantics to writes to volatile variables in ..NET 2.x", then that's basically correct: both imply a release barrier before the write, and neither guarantee remote write atomicity (i.e. different processors can observe the writes in a different order). The same is true of reads, BTW: ordinary reads from WB memory in x86 and from volatiles in ..NET 2.x both imply an acquire barrier after the read. [*] C99 6.7.3 #6 "What constitutes an access to an object that has volatile-qualified type is implementation-defined." is one get-out clause; the lack of any specification of multi-threaded semantics by C is another. -- David Hopwood .