NightStrike <nightstrike@xxxxxxxxx> 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 > libraries). 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 to either. > 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 to memory. 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. Ian
