[cpp-threads] A niggle on the atomic model (N2145)

Nick Maclaren nmm1 at cus.cam.ac.uk
Tue Apr 24 10:32:32 BST 2007


"Boehm, Hans" <hans.boehm at hp.com> wrote:
>
> > Well, my copy of the Alpha architecture says at the end of 4-12
>
> The one I just downloaded states:
>
> ...
>
> That's what I would have expected.

Mine is the original one!  It is almost certain that they were fairly
liberal in the original one, and decided that it was such a pain to
implement that they tightened it up.

> I'm not sure we actually have any direct control over this, since I
> don't believe it's possible to create such mappings in a pure C++
> program.  I think Posix, as an important example, currently doesn't
> prohibit it.

We don't, I agree, and it doesn't.  But most POSIX-conforming systems
pretty strongly discourage such tricks, even when they don't forbid
them, and I am 90% sure that doing that will not work at all reliably.

> Since we're only talking about single location atomic operations, I'm
> still not completely sure whether anything at the C++ level breaks
> unexpectedly.  But I think we're not promising anything to start with.

That is all I want.  My point isn't that this can't be made to work,
but that it is a hostage to fortune, for a negligible gain.  Any
programmer who maps the same shared entity into memory in two different
locations in the same address space, with at least one being updated,
is pointing a gun at his foot and pulling the trigger.

We should simply say nothing about such lunacies.  I agree that it is
essential that shared update to two different addresses in separate
address spaces should work if an implementation uses processes to
implement C++ threading.  But that is MUCH cleaner!


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



More information about the cpp-threads mailing list