This is the mail archive of the
mailing list for the GCC project.
Re: volatile shared memory
NightStrike <firstname.lastname@example.org> writes:
> If I am interacting with shared memory, gcc doesn't know if another
> process changes values. This creates issues for optimization. I know
> that "volatile" can help address this, but it winds up causing a giant
> mess of other problems (like, for instance, I can't pass a volatile
> into memcpy.. or pretty much anything else from the standard
No, volatile can not address this. This is not what the volatile
qualifier is for. The volatile qualifier is designed for working with
memory mapped hardware. It is not designed for multi-processor shared
memory. If a program is not multi-processor safe, then adding volatile
will never make it multi-processor safe.
This is because the issues related to making code multi-processor safe
are related to memory barriers and memory cache behaviour. Adding a
volatile qualifier will not change the program's behaviour with respect
> So for instance, if I do something stupidly simple like busy-wait on a
> shm value to change:
> while (shm->index == oldindex) ;
> gcc will kill that loop.
Just as well, since the program is most likely incorrect anyhow.
Without any memory barrier, that expression could become true even
though the executing processor can't see any of the other changes made
Don't think volatile. Think memory barriers invoked via asm
constructs. Use the new atomic builtins.
And I can't help but add that most programs that work at this level get
it wrong. Better to use mutexes and condition variables. Or even
higher level constructs.