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: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-01-12 15:42:34

Le 12/01/13 19:50, Andrey Semashev a écrit :
> 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.
This is what I was looking for as it is intended by the typedef name, 
that is the larger unsigned integer type that can be atomic for a 
specific platform.
>
> 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.
>
I don't see how Boost.Thread can use Boost.Atomic internally. What do 
you mean? linking statically? Shouldn't this generate a double 
definition on the executable if the application needs Boost.Atomic?

Vicente