[cpp-threads] Re: A hopefully clearer document on POSIX threads

[Hans Boehm]

To be honest, I agree that this is an issue, but not one that I think we
can address.

Speaking (as usual) purely for myself, and not HP, it seems to me that:

1) The current X86 memory model is not particularly clear.  There seem to
be political/legal reasons (partly related to the fact that often no one
company controls the memory model, since it's a function of both the
processor and support chips) that this will not get officially fixed.

2) There is lots of software that assumes a "de facto X86 memory model",
which is enforced by all current chips.  That enforces transitivity.
Current Java implementations assume this model.

3) Given that it is critical for both Intel and AMD to make it easier to
program to chip multiprocessors, I would be surprised to see them release
anything with a weaker memory model than the current "de facto" one.

4) If they do release something with a weaker model, code breaks, though
probably in subtle ways, until it is recompiled or, for Java and .NET,
until the VM is replaced.  I agree that this would be a major hiccup,
which is why I think there will be strong pressure to avoid it.  If it
does happen, based on the proposed spec, the fault clearly lies with the
compiler and/or hardware vendor.  In the absence of a better X86 spec, we
can't do better than that.  (There may be a way to guard against this, at
some performance cost, by having many of the atomic operations on X86 go
through a dynamic library, which can be replaced without recompilation.)

The only way to avoid this would be to have all compilers assume the
weakest memory model that is clearly guaranteed by the X86 spec.  Based on
my reading of the spec, that's not viable.  I don't see any reasonable
alternative for the C++ spec that would help matters in this respect.  If
anyone does, let me know.  Removing the transitivity requirements for
volatile/aquire-release operations strikes me as too horrible to
contemplate.  I don't think the result would be at all usable.

Hans

On Sat, 11 Mar 2006, Nick Maclaren wrote:

> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> >
> > I believe that the current strawman proposal states that the assertion
> > can fail if
> >
> > - Ordinary loads and stores are involved (obviously, there are many
> > races).
> >
> > - If all the loads and stores are atomic, but unordered.  The load of x
> > in P1 still happens-before the store of y, since the latter depends-on
> > the former.  But the same is not true for the loads in P2, since
> > currently only stores depend-on loads.
> >
> > If additionally the load of y in P2 is an acquire load, then the
> > assertion is guaranteed to succeed.
> >
> > This means that for now, X86 load_acquires can be ordinary loads.  If
> > any future X86 processors fail to enforce this sort of transitivity,
> > then that will no longer be the case, and load_acquire will need a more
> > expensive implementation, as will Java volatile loads.
> >
> > I'm personally OK with all of this.  Is everyone else?
>
> No.  You have completely lost me.  Let's say that a future x86 fails
> to enforce the transitivity, so the program fails.  A user then comes
> to me and moans, I spend a week tracking things down and get proof
> of the effect.  Do I then:
>
>     1) Tell the user that he has misunderstood the standard, that he
> can't trust the ordinary rules of logic when reading the standard,
> and should write his code accordingly?
>
>     2) Report it to the compiler vendor as a bug in their code, caused
> by a change in x86 behaviour, and dedicate a month's work to bulling
> that through with no very great hope of success?
>
>     3) Classify it as yet another ambiguity in the standard, tell
> both the user and the vendor of the issue, and wash my hands of the
> horrible mess?
>
> Look, I don't really CARE what the rules are, provided that they are
> consistent, implementable, usable and above all CLEAR!
>
>
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service,
> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> Email:  nmm1 at cam.ac.uk
> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>