My question is quite simple. Why isn\'t std::atomic
implemented completely? I know it has to do with atomic RMW (read-modify-write) access. But I
The standard library mandates std::atomic<T>
where T is any TriviallyCopyable
type. Since double
is TriviallyCopyable
, std::atomic<double>
should compile and work perfectly well.
If it does not, you have a faulty library.
Edit: since comment clarifying the question:
The c++ standard specifies specific specialisations for fundamental integral types. (i.e. types that contain integers that are required to be present in the language). These specialisations have further requirements to the general case of atomic, in that they must support:
OR, XOR, AND are of course not relevant for floating types and indeed even comparisons start to become tricky (because of the need to handle the epsilon). So it seems unreasonable to mandate that library maintainers make available specific specialisations when there is no case to support the demand.
There is of course nothing to prevent a library maintainer from providing this specialisation in the unlikely event that a given architecture supports the atomic exclusive-or of two doubles (it never will!).
std::atomic<double>
is supported in the sense that you can create one in your program and it will work under the rules of C++11. You can perform loads and stores with it and do compare-exchange and the like.
The standard specifies that arithmetic operations (+, *, +=, &, etc.) are only provided for atomics of "integral types", so an std::atomic<double>
won't have any of those operations defined.
My understanding is that, because there is little support for fetch-add or any other atomic arithmetic operations for floating point types in hardware in use today, the C++ standard doesn't provide the operators for them because they would have to be implemented inefficiently.
(edit). As an aside, std::atomic<double>
in VS2015RC is lock-free.