Re: C++0x Memory model and gcc

[Ian Lance Taylor <iant at google dot com>]

Michael Matz <matz@suse.de> writes:

> On Wed, 12 May 2010, Andrew MacLeod wrote:
>
>> Well, you get the same thing you get today.  Any synchronization done 
>> via a function call will tend to be correct since we never move shared 
>> memory operations across calls.  Depending on your application, the 
>> types of data races the options deal with may not be an issue.  Using 
>> the options will eliminate having to think whether they are issues or 
>> not at a (hopefully) small cost.
>> 
>> Since the atomic operations are being built into the compiler, the 
>> intent is to eventually optimize and inline them for speed... and in the 
>> best case, simply result in a load or store. That's further work of 
>> course, but these options are laying some of the groundwork.
>
> Are you and the other proponents of that memory model seriously proposing 
> it as an alternative to explicit locking via atomic builtins (that map to 
> some form of atomic instructions)?

I'm not sure what you mean here.  Do you an alternative way to
implement the C++0x proposed standard?  Or are you questioning the
approach taken by the standard?

Ian