Re: [boost] Fw: [atomic] review results

Subject: Re: [boost] Fw: [atomic] review results
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-08 07:24:22

> > 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