Michael Matz <m...@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
