Re: volatile shared memory

[NightStrike <nightstrike@xxxxxxxxx>]

On Fri, Mar 16, 2012 at 12:21 AM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
> 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.

Do you have to use volatile if you're writing to memory mapped
hardware, or just reading?

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

Is caching the reason that makes another process sharing a memory
address different than a piece of hardware sharing a memory address?

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

I thought (probably incorrectly) that the atomic builtins were only
for atomic actions between threads in a process, not between separate
processes.  Do they really work with the latter?  The information I
got on freenode's #gcc (not oftc) was that gcc can't do anything to
protect shared memory between processes, that you have to use a system
semaphore feature.

> 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