in my reading the sentence `The implementation should not depend on any per- process state' is not restricted to lock-free atomics, but i am not a native speaker and i could be wrong.
neither am I but from the following full excerpt as quoted by Peter Dimov:
[ Note: Operations that are lock-free should also be address-free. That is, atomic operations on the same memory location via two different addresses will communicate atomically. The implementation should not depend on any per-process state. This restriction enables communication by memory that is mapped into a process more than once and by memory that is shared between two processes. —end note ]
I think that "address-free" clearly applies only to "lock-free", and if something is not "address-free" then the point whether it can be used interprocess is kind of moot as it is most certainly not going to be mapped at the same address (if you consider numerically identical addresses in different spaces to be the same at all).
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. there is no standard-compliant way to test at compile- time if std::atomic<T> is lock-free. 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, so one cannot write a metafunction to dispatch at compile time .... tim