On January 13, 2013 12:42:34 AM "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> 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.