[cpp-threads] High-level vs. low-level

Peter Dimov pdimov at mmltd.net
Thu Jul 13 20:25:02 BST 2006


Herb Sutter wrote:

> Leaving aside the difficulty of fences, a secondary issue with the
> above is that from the point of view of language design this
> multiplies the opportunities to go wrong -- specifically because it
> requires the programmer to remember to say something special
> (potentially) each time they read and write the variable, and each
> time is an opportunity for the programmer to be human and forget,
> with no safety net and silent compilation. At the very least, even
> for the rocket scientists who'd want to do the above, wouldn't you
> prefer to be able to declare x as a type that doesn't have regular
> assignment available at all, and so _requires_ the programmer to
> write code like the above (including e.g. atomic_store_normal when no
> special fencing is required) so that you get a compile-time error
> when you forget? Otherwise it's way too easy to forget, and I don't
> believe the code is maintainable (experts might get the initial
> coding right, but I don't believe it has a good chance to stay right
> in the face of maintenance).

This is a very good question. I'm still undecided on whether:

    atomic_load_acq( &x );

should work on x being a plain int. It is possible to restrict the library 
to require the programmer to tag the x as allowing atomic operations. One 
problem with such a restriction is that it either requires changes to the 
type system:

    int __atomic x;

overloading volatile:

    int volatile x;

or restricting the library to C++:

    std::atomic<int> x;

In my mind, atomic_load_acq is ideally a C/C++ compiler built-in.

At the moment I favor the unpopular "here's the gun, watch your feet" 
approach of operating on arbitrary (suitably size/alignment restricted) 
PODs.

In principle, the type restrictions would almost certainly be 
"implementation defined", so an implementation would be within its rights to 
only operate on specially tagged objects. In practice, though, I expect all 
implementations to accept ordinary ints.




More information about the cpp-threads mailing list