Memory model

[Boehm, Hans]

My model is basically the same as Doug's.  We are defining a set of
rules that should be obeyed by all implementations.  But probably very
little of what we come up with, if anything, will be visible to
single-threaded code.  Hence you can't get caught cheating for
single-threaded code.  (Is a program that uses asynchronous signals
ever single-threaded?  Does anything we do have any bearing on
asynchronous signals?)

I expect that compilers will end up supporting flags that to assert that
a program is single-threaded.  But I don't think that can be the
default as it often is now.  And I would like to see them become
basically benchmark-only options.

I think we should minimize ABI breakage, but I don't think we can avoid it
completely.  And there is no question that we will add optimization
constraints; to guarantee that your program obeys the memory model, you
will have to recompile anyway.

I suspect we have to break some ABIs, since I don't think they all
agree on questions which I think we will have to resolve.  A canonical
one seems to be whether function local statics are constructed exactly once,
even in the presence of threads. (I don't know what the current
status is on that.)

I expect that the least intrusive route we could take is to keep the
meaning of races on ordinary variables (defined with respect to
sequential consistency) undefined.

Hans

> -----Original Message-----
> From: Kevlin Henney [mailto:kevlin at curbralan.com]
> Sent: Thursday, January 27, 2005 2:02 AM
> To: dl at cs.oswego.edu
> Cc: Boehm, Hans; Andrei Alexandrescu; dl at altair.cs.oswego.edu; Maged
> Michael; Ben Hutchings; Peter A. Buhr; pugh at cs.umd.edu
> Subject: Re: Memory model
> 
> 
> In message <16888.16337.789831.734945 at altair.cs.oswego.edu>, Doug Lea 
> <dl at cs.oswego.edu> writes
> >>
> >> To continue the previous point, this raises the question 
> of degree of
> >> conformance required for any memory model proposed. Is the 
> model truly
> >> general so that, in the limit with a single thread, it 
> also specifies
> >> conformance for existing C++ sequential code? Or is it an optional
> >> extra, ie if there is more than a single thread active in 
> the code then
> >> a memory and execution model must conform to this newly 
> standardised
> >> behaviour?
> >
> >The easiest way to deal with this is to ignore it.  One of 
> the slogans
> >compiler optimization developers is "everything is legal if you can't
> >get caught".  How bad would it be if overwriting fields etc 
> were legal
> >only for compilers doing whole-program analysis that can prove that
> >only a single thread is created (and thus, they will 
> provably never be
> >caught)?  In some cases, less-than-whole-program analysis would
> >suffice.  Overwrites and the like are not all that important for
> >performance. I don't think many compiler folks will complain 
> that they
> >can only do them in very restrictive circumstances.
> 
> Global or even local analysis is not the issue. C++ programs are 
> normally configured wrt thread-library usage at build time. The fact 
> that there is more than one way to compile and link a program is an 
> awkward fact that must be dealt with. My concern was with whether 
> dealing with overlapped writes would affect any existing ABIs 
> -- any ABI 
> breakage would meet resistance regardless of the other qualities of a 
> coherent threading model.
> 
> Kevlin
> -- 
> ____________________________________________________________
> 
>    Kevlin Henney                   phone:  +44 117 942 2990
>    mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
>    http://www.curbralan.com        fax:    +44 870 052 2289
>    Curbralan: Consultancy + Training + Development + Review
> ____________________________________________________________
>