Tim Blechmann wrote:
this implies that one can only use atomic integral types in shared memory, but not std::atomic<>, because the std::atomic<> template has a per-instance is_lock_free member.
29.4/2: "The function atomic_is_lock_free (29.6) indicates whether the object is lock-free. In any given program execution, the result of the lock-free query shall be consistent for all pointers of the same type." The query is not per-instance. It can't be performed at compile time though (this is probably motivated by instruction set differences like the famous 386-486 divide where the program can only know at run time whether general atomics are available).
i cannot find any reference in the standard, that std::atomic<T> is lockfree, if there is a lockfree integral atomic type of the same size, ...
As a practical matter, it will be. Pedantically speaking, it is not possible to give this guarantee in the general case, because the integral type may have padding bits and trap representations. But I don't think that this is true on any platform that provides atomic operations, so in practice, we should be fine (although it's possible for an implementation to do the wrong thing in principle, but I doubt that many will).