On Mon, 2007-10-22 at 00:07 +0100, Dave Korn wrote: > If you really want all externally-visible accesses to v to be made exactly > as the code directs, rather than allowing gcc to optimise them in any way that > (from the program's POV) it's just the same 'as-if' they had been done > exactly, make v volatile.
That is not enough. Apart from the lack of ISO semantics for volatile, typically a compiler will take volatile as a hint to not hold values of the variable in a register. On a multi-processor, this is not enough, because each CPU may still hold modified values in separate caches. Perhaps gcc actually puts a RW barrier to force cache synchronisation on every volatile access.. this seems rather expensive and very hard to do since it is very dependent on the actual box (not just the processor). Some processor caches might require external electrical signals to synchronise, for example. This is quite possible if you have multiple CPU boards in a box. But I don't actually know what gcc does, although I guess it does nothing. The OS has to do the right thing here when a mutex is locked etc, but the code for that is probably in the kernel which is better able to manage things like cache synchronisation than a compiler. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
