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