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

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

> > > 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 ....
> that's both correct and very annoying indeed -- for Boost.Atomic this
> property of course holds true and I can create a "type trait"-like class to
> perform the required mapping (maybe would have made sense for C++11 as
> well) -- this assumption also sounds reasonable enough that there may be
> justification for boost to offer such a type trait for atomics of the
> platform compiler.

i double-checked:

atomic_is_lock_free:
takes the argument `atomic-type', not `atomic-integral': this means it should 
also support atomic<T>. to me this sounds like atomic<T>::is_lock_free should 
have the same semantics, althought it is not mentioned anywhere ...

tim