Re: C++0x Memory model and gcc

[Andrew MacLeod <amacleod at redhat dot com>]

Miles Bader wrote:
> Andrew MacLeod <amacleod@redhat.com> writes:
>   
> > > > -fmemory-model=single     - Enable all data races introductions, as they
> > > > are today. (relax all 4 internal restrictions.)
> > > >         
> > > One could still use this mode with a multi-threaded program as long as
> > > explicit synchronization is done, right?
> > >       
> > Right.  Its just a single processor memory model, so it doesn't limit
> > any optimizations.
> >     
>
> Hmm, though now that I think about it, I'm not exactly sure what I mean
> by "explicit synchronization".  Standard libraries (boost threads, the
> upcoming std::thread) provide things like mutexes and
> conditional-variables, but does using those guarantee that the right
> things happen with any shared data-structures they're used to
> coordinate...?
>
>   

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.

Andrew