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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-01-12 13:50:34

On January 12, 2013 9:57:22 PM "Vicente J. Botet Escriba" 
<vicente.botet_at_[hidden]> wrote:
>
> 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.

The algorithm is different for sure. What exactly do you mean by C++11 
interface? Does C++11 have call_once? The only C++11 thing I saw was 
the once_flag definition which gave no apparent benefits.

> What I was asking for is just a
> patch to ensure that
>
>      typedef unsigned long  uintmax_atomic_t;
>
> is atomic in all platforms.

Boost.Atomic only provides atomic<> template, it does not define the 
functional interface for atomic ops. The typedef you mentioned can only 
be the following with Boost.Atomic:

  typedef atomic< unsigned long > uintmax_atomic_t;

The integer type can be different from unsigned long, depending on the 
platform-specific support macros, but you get the idea. This is *not* 
what I proposed because, obviously, this would require including 
Boost.Atomic into user's code and consequently linking with it.

As a side note, the standard doesn't specify the underlying storage 
types for the atomic<> wrapper. Whenever you try to use atomic ops on 
actual integer types you are relying on platform-specific details, 
which Boost.Atomic is designed to conceal.

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

That's right. Again, my proposal was to use Boost.Atomic in 
Boost.Thread internally and not expose it to users. That way 
Boost.Thread links with Boost.Atomic, but users do not.