Re: [boost] [thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?

Subject: Re: [boost] [thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?
From: Tim Blechmann (tim_at_[hidden])
Date: 2013-01-12 13:20:14

>>> >> Anyway, could you send the resulting files to make easier the review?
>> > The files are attached. These should be boost/thread/posix/once.hpp and
>> > libs/thread/src/posix/once.cpp, other files are intact.
>> >
> Andrey, the provided patch goes too far for what I was expecting. You 
> have made a lot of changes, C++11 interface has not been preserved, and 
> I'm not sure the algorithm is the same. What I was asking for is just a 
> patch to ensure that
> 
>      typedef unsigned long  uintmax_atomic_t;
> 
> is atomic in all platforms.

i suppose this is the case for most platforms. however according to the
c++11 standard only atomic_flag is guaranteed to be lockfree,
unfortunately we cannot guarantee this for boost.atomic (without some
additional platform-specific code).

> For the comments about the Jamfile, I deduce that the patch need to link 
> with Boost.Atomic. I expected a patch that didn't need to link to 
> Boost.Atomic. I should have missed something.

again, this is something we cannot guarantee for boost.atomic. during
the review the original author wanted to provide an implementation of
atomic<> that is address-free that should have become part of
boost.interprocess ... well, that was before he disappeared. that
implementation could have been header-only, as every atomic<> would have
been associated with a spin-lock (or every non-lockfree atomic<> if we
decide not to care about binary compatibility)

but i wonder: is it a problem to link boost.thread with boost.atomic?

cheers, tim