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 16:48:47

On January 13, 2013 12:42:34 AM "Vicente J. Botet Escriba" 
<vicente.botet_at_[hidden]> wrote:
> >
> > 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 [1]. 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).

[1] 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.