Memory model

Kevlin Henney kevlin at curbralan.com
Thu Jan 27 10:01:52 GMT 2005


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
____________________________________________________________






More information about the cpp-threads mailing list