Re: C++0x Memory model and gcc

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 17 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)?
> 
> Proposing what as an alternative?

The guarantees you seem to want to establish by the proposed memory model.  
Possibly I misunderstood.

I'm not 100% sure on the guarantees you want to establish.  The proposed 
model seems to merge multiple concepts together, all related to 
memory access ordering and atomicity, but with different scope and 
difficulty to guarantee.

The mail to which I reacted seemed to me to imply that you would believe 
the guarantees from the memory model alone would relieve users from 
writing explicit atomic instructions for data synchronization.

If you didn't imply that, then I'm also interested to learn what other 
advantages you expect to derive from the guarantees.

And third, I'm interested to learn how you intend to actually guarantee 
the guarantees given by the model.

So, in short, I'd like to know
  What (guarantees are established),
  Why (are those sensible and useful), and
  How (are those intended to be implemented)

I've tried to find this in the Wiki, but it only states some broad goals 
it seems (not introduce data races).  I also find the papers of Boehm 
somewhat lacking when it comes to how to actually implement the whole 
model on hardware, especially because he himself acknowledges the obvious 
problems on real hardware, like:
  * load/store reorder buffers,
  * store->load forwarding,
  * cache-line granularity even for strict coherency models, 
  * existence of weak coherency machines (have to aquire whole cache line
    for exlusive write)
  * general slowness of locked (or atomic) instructions compared to normal
    stores/loads
  * existence of store granularity on some hardware (we don't even have to 
    enter bit-field business, alpha e.g. has only 64 bit accesses)

But for all of these to be relevant questions we first need to know what 
exactly are the intended guarantees of that model; say from the 
perspective of observable behaviour from other threads.

> These optimization restrictions defined by the memory model are there to 
> create predictable memory behaviour across threads.

With our without use of atomics?  I.e. is the mem behaviour supposed to be 
predictable also in absense of all mentions of explicitely written atomic 
builtins?  And you need to defined predictable.  Predictable == behaves 
according to rules.  What are the rules?

> This is applicable when you use the atomic built-ins for locking.  
> Especially in the case when the atomic operation is inlined.  One goal 
> is to have unoptimized program behaviour be consistent with the 
> optimized version.

We have that now (because atomics are memory barriers), so that's probably 
not why the model was devised.


Ciao,
Michael.