This is the mail archive of the gcc-help@gcc.gnu.org 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


On Fri, Mar 16, 2012 at 12:21 AM, Ian Lance Taylor <iant@google.com> wrote:
> NightStrike <nightstrike@gmail.com> 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.
Would you be able to paste the verbiage from the C or C++ standard? (I
don't have a coy of the standard).

The reason I ask is Microsoft appears to have a different
interpretation of the qualifier [1], and does not limit 'volatile' to
memory mapped hardware.

Jeff

[1] http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.90).aspx


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