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
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk