[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