C++0x Memory model and gcc
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