Memory model

[Ben Hutchings]

Hans Boehm wrote:
> 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.

That makes sense to me.

> (Is a program that uses asynchronous signals
> ever single-threaded?  Does anything we do have any bearing on
> asynchronous signals?)

Perhaps, as any operations that are atomic w.r.t. other threads are
likely to be atomic w.r.t. asynchronous signals too, and a guarantee of
that might be useful to some programs.

> 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.)

The Itanium C++ ABI doesn't absolutely require it, but defines a means
to do so: <http://www.codesourcery.com/cxx-abi/abi.html#once-ctor>.
(The pseudo-code there uses "double-checked locking", but the following
text does note the need for an acquire memory barrier on the first
check.)

> 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.

Where we're unsure what may or may not break binary compatibility, would
it not be reasonable to present the committee with both a conservative
and an ideal resolution, leaving it to implementers to work out what's
going to cause real compatibility problems?

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                                    A fail-safe circuit will destroy others.