This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: volatile shared memory

NightStrike <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]