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 16:48:47
On January 13, 2013 12:42:34 AM "Vicente J. Botet Escriba"
> > 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.
Like I said, you won't be able to select such a type without including
Boost.Atomic in the user's code.
> > 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?
My patch demonstrates how this could be achieved.
Boost.Thread should never link statically to any libs, not just
Boost.Atomic. Here is why:
1. Linking only happen when you build the dynamic library of
Boost.Thread. If an application uses the dynamic lib of Boost.Thread,
chances are high that the application is multi-module, and you cannot
know if it doesn't use Boost.Atomic or Boost.System on its own. If
Boost.Thread links dynamically to other Boost libs, it is safe for the
application to link dynamically with them as well if it uses them in
its own code. If the application doesn't use Boost.Atomic on its own
then it doesn't link to it.
2. When you build a static lib of Boost.Thread, you don't link. The
resulting archive doesn't contain other Boost libs, it only refers to
the symbols of those libs. The application can link Boost.Thread
statically and other libs statically or dynamically, depending on its
needs . However, according to my practice, you either link all
libraries statically (which is a typical case for monolithic
applications) or you link everything dynamically. Mixed linking is a
very rare case and is typically discouraged.
Unfortunately, in the second case the application will have to link
Boost.Atomic explicitly if Boost.Thread uses Boost.Atomic in a way that
involves the spinlock pool (which is unlikely with my patch since it
uses only 32 bit atomic ops).
 This will not work on Windows because it mangles symbols
differently when exporting from static or dynamic libs. But I don't see
it as a big problem; everything will be fine as long as you follow the
"all static or all dynamic" rule.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk