On 22 October 2007 02:20, skaller wrote:
> 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.
Yes. volatile's job is to make the compiler issue real memory load and
store operations when and where you say in the code. Beyond that it's all up
to you, just like fflush doesn't guarantee the kernel/filesystem write-back
cache is emptied, only the C runtime library buffer.
> But I don't actually know what gcc does, although I guess
> it does nothing.
Yep.
> 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.
The OS and the system libc together, yes.
cheers,
DaveK
--
Can't think of a witty .sigline today....
