[cpp-threads] memory model

[Boehm, Hans]

> -----Original Message-----
> From: Peter Dimov
> I don't believe that total order is implied anywhere. 
> Function invocation is 
> the canonical example of lack of total order. There are no 
> sequence points 
> between the evaluation of the arguments. In your example f( 
> (a, b), c ), the 
> comma operator introduces a sequence point between a and b, but this 
> sequence point only orders a and b, not c.
> 
> (a, b) + (c, d) is another example.
> 
> You can ask in c++std-core if you want an authoritative 
> opinion, but I'm 
> pretty certain that sequence points only impose partial ordering.
My problem with all of this is that the standard only talks about the
position of the sequence points in an execution.  Thus if I
have f((a,b), (c,d)) with an execution of, for example:

1: <evaluate a>
2: <evaluate b>
3: <evaluate c>
4: <evaluate d>
5: <call f>

then the standard tells me there are sequence points between 1 and 2
and 3 and 4.  I know that a and d can be executed in any order, and
I'm positive the committee agrees, but I don't see how sequence points
say that.

> Yes; my point was that the presence of a constructor does not change 
> anything, we get the same visibility issue if X is an int or a POD.
I added a comment that effect
> 
> > Sounds reasonable to me.  (I actually think __thread is 
> quite useful 
> > without this, since you at least get __thread pointers, 
> which is what 
> > I tend to use.  And unlike pthread_..._specific, I think they're 
> > generally faster than what I can implement myself.)
> >
> > I'll put it in for now.  I expect the only disagreement we 
> might get 
> > is from implementors.
> 
> I can implement it in a library, so it must be possible to 
> implement it in 
> the language as well, right? ;-) 
> 
I don't see why it should be tremendously difficult either.  I expect
you do want this to work even if the threads are created with
pthread_create, or some other similar mechanism supported on the
platform.  Thus you presumably need hooks into pthread startup,
or whatever.  And presumably dynamic library unloading now needs
to know about destructors for thread locals.  This all sounds possible,
but I suspect it involves actual work.  And the work isn't confined
to compiler groups.

Hans