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


Jeffrey Walton <noloader@gmail.com> writes:

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

Section 6.7.3, paragraph 6

    An object that has volatile-qualified type may be modified in ways
    unknown to the implementation or have other unknown side effects.
    Therefore any expression referring to such an object shall be
    evaluated strictly according to the rules of the abstract machine,
    as described in 5.1.2.3.  Furthermore, at every sequence point the
    value last stored in the object shall agree with that prescribed by
    the abstract machine, except as modified by the unknown factors
    mentioned previously.(114)  What constitutes an access to an object
    that has volatile-qualified type is implementation-defined.

Footnote 114 (non-normative):

    (114) A volatile declaration may be used to describe an object
    corresponding to a memory-mapped input/output port or an object
    accessed by an asynchronously interrupting function.  Actions on
    objects so declared shall not be "optimized out" by an
    implementation or reordered except as permitted by the rules for
    evaluating expressions.


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

That is a choice made by Microsoft (in my opinion, an unfortunate one).
You will note that all the relevant docs are in a section labelled
"Microsoft Specific."  The important addition that Microsoft is making
is that writes to a volatile object have release semantics and reads of
a volatile object have acquire semantics.  That is not in the language
standard.

Ian


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