Subject: Re: [boost] Fw: [atomic] review results
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-11-08 08:25:49
On Tuesday 08 November 2011 13:24:22 Tim Blechmann wrote:
> > > 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 ....
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.
lacking appropriate integer types there is BTW currently also no way to query
for atomicity of objects of several sizes