C++0x Memory model and gcc

Michael Matz matz@suse.de
Mon May 17 13:12:00 GMT 2010


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)?


More information about the Gcc mailing list