[cpp-threads] Memory model counterproposal: synchronizedoperations

[Boehm, Hans]

I believe that we will effectively disallow very little optimization.
We're preserving the fundamental (unstated) observation that seemed to
be behind the pthread standard:  So long as a compiler treats
synchronization
points as opaque, it can move memory references between synchronization
points.  Another thread can notice this transformation only by
introducing a data race, which would invoke undefined behavior.

The existing transformations that cause problems are basically
those that introduce writes that were not apparent in the source,
as opposed to just moving them around.  As was pointed out in 
the Java discussion, in the Java memory model paper, and in my paper,
certain transformations and analyses assume this is safe.  But I
think those all have slightly more conservative counterparts that
don't.

Generally the dubious transformations are the ones that introduce
stores to memory, either for structure assignment reasons, or because
they result in speculatively executed code.

The ones I'm currently most worried about are:

- Speculative register promotion.  Promoting a "global" to a
register inside a loop is no longer safe, if the loop contains
rarely executed function calls that may require spilling and
reloading the register around the call.  It is still safe for
loops that contain no calls.  (I think Mark Davis pointed out
that this problem isn't confined to loops.  But tight loops
with a call to an error handling routine are probably the worst
case.)

- (section 9.1.1 of the POPL Java memory model paper)  The definition
of control dependence changes.  You can no longer move code
above loops unless you can prove the loop terminates.  I expect
that for a large fraction of loops you can't.  (E.g.
the vast majority of compilers can probably prove
that  "for (p = x; p != 0; p = p->next) count++;" only if
they know that x == 0.

Note that Java compilers already operate (or should operate)
under these rules.  And many of them in fact do a very reasonable
job for code in which the language doesn't require
additional indirections, allocation, or the like.

The fact that the current strawman proposal mentions sequential
consistency a lot does NOT mean that we are requiring compiled
code to obey sequential consistency rules.  That seems to be a
regular source of confusion.

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 27, 2005 8:13 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] Memory model counterproposal: 
> synchronizedoperations
> 
> 
> Nelson, Clark wrote:
> >> I don't have any voting power, of course, but if I did, I'd vote 
> >> against the restriction.
> >
> > OK, that's fine. But for what kind of restriction would you vote?
> >
> > Or perhaps there's a more basic question: do you think 
> that, without 
> > some sort of explicit restriction in the standard, there 
> will still be 
> > room for optimization? My problem is, I don't think so.
> 
> Yes, I believe that there will stil be room for optimization 
> even if all 
> variables are potentially visible to all threads. Today the 
> case is that all 
> variables are potentially visible to all functions, but the 
> compilers can 
> and do prove that some optimizations are safe.
> 
> It might be that you have a specific situation in mind that I didn't 
> consider, of course. 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk