[cpp-threads] memory model

[Boehm, Hans]

The more I look at this, the less I understand what the actual model
is here.  I expect we need to take this to the core list.  My
fundamental problem is that the standard talks about the placement
of sequence points in the "execution sequence".  But I think
both of us believe that sequence points are meant to constrain
the possible execution sequences.

An alternate interpretation seems to be that execution sequences are
otherwise specified, and sequence points constrain the order in
which "side effects" become visible to the outside world.  That seems
to be closer to what the text actually states, but then I'm not sure
that acceptable execution sequences are sufficiently specified.

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Peter Dimov
> Sent: Friday, May 06, 2005 3:23 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] memory model
> 
> 
> Boehm, Hans wrote:
> >> (a, b) + (c, d) is another example.
> >
> > 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.
> 
> Once you choose an execution, the order is fixed, and the concept of 
> sequence points is no longer relevant. But the above is not the only 
> possible execution.
> 
> 1: <evaluate c>
> 2: <evaluate a>
> 3: <evaluate b>
> 4: <evaluate d>
> 5: <call f>
> 
> If a and c are complex expressions, 1 and 2 can also be interleaved.
> 
> The sequence points impose constraints on the set of possible 
> executions. 
> They aren't applied to the execution itself. At least this is my 
> understanding of the concept. In fact there is no standard 
> requirement for a 
> and c to even be evaluated sequentially; they can be 
> evaluated in parallel. 
> There is a requirement that writes to the same object must be 
> separated by a 
> sequence point (else the behavior is undefined), so this 
> parallel execution 
> is guaranteed not to have races. 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk