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

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

Best regards
Helge