skaller <[EMAIL PROTECTED]> writes: > As I understand it volatile is typically used as a 'hint' > to the compiler that there could be aliases it cannot see. > This is independent of the use suggesting asynchronous changes > in a hardware port for example, although the effect is the same.
Not really. Volatile has a reasonably precise definition: it means that memory accesses must be done precisely as they are written in the program. They may not be coalesced, and they may not be moved. > So: accesses to any variable read or written > whilst protected by a lock are ordered with respect > to any other accesses protected by a lock in any > other thread, whether or not the variable is aliased > or volatile. Yes. > I'm deducing this from existing practice NOT any standards: > in this circumstance, volatile is NOT needed. That is correct: it's not needed if there is a lock, access, unlock sequence. In the example which started this brouhaha, there was no unlock. > That leaves open several questions. One is: what can > we say about a write in thread A *prior* to a lock > being set and released, and a read in thread B > *after* a lock is set and released, where the read > is certain to be following the write temporaly, > for a variable NOT accessed during the exclusion period > by either thread? A correct mutex implementation is required to use compiler specific magic to implement a memory barrier. In gcc, this magic is implement via an inline asm. This memory barrier will impose the natural ordering requirements. > And in effect that means ALL variables must be synchronised, > unless the compiler is exceedingly smart! No, it means that the implementation of mutex must be magic. > [BTW I think this sucks, the need to synchronise ALL memory > on mutexing is far too heavy] It can not be avoided, for the reasons you describe. Ian
