在 Linux 上正确链接 boost 多线程库

Question

我对是否链接 libboot_*-mt 变体以及它们的实际用途有点困惑。

我在 Centos 6 上使用 boost 1.46.0 的自定义反向移植。该构建生成 /usr/lib64/libboost_thread-mt.so.7 以及 -mt 和其他库的标准版本。

我编写了一个单元测试程序，它使用线程将计算存储在 boost::future 中。要链接该测试，我必须添加 -lboost_thread-mt。但是我不需要更改其他 boost -l args 来使用 -mt 版本。

我读过Library Naming boost 站点上的部分，但我不清楚“表明该库是在启用多线程支持的情况下构建的。没有多线程支持的库可以通过缺少 -mt 来识别”实际上是什么意思。

1. 如果我与 -lboost_thread-mt 链接，是否需要切换到其他库的多线程感知版本？如果没有，我什么时候需要链接 -mt 变体？

2. 是否建议仅在需要时选择性地链接 -mt 变体？该项目使用 GNU Make 进行构建。

3. 总是链接到 -mt 变体是否会导致性能或功能损失？

Answer 1

当您在 bjam 行中设置 threading=multi 时，将构建“mt”变体。 “mt”选项的后果之一是定义了BOOST_HAS_THREADS。

当然，您链接的所有 boost 库都应该是相同的变体，这与您的应用程序的线程匹配。否则，您最终可能会违反 ODR：假设在库 A 中编译 shared_ptr 时没有 BOOST_HAS_THREADS，而库 B - 使用 BOOST_HAS_THREADS。这两个shared_ptr 具有完全不同的自旋锁类实现。因此，如果您从库 A 获得 shared_ptr 并将其传递给库 B，您的程序就会崩溃。此外，mt 和非 mt 变体可能使用不同的堆。

（也就是说，值得一提的是 BOOST_HAS_THREADS 依赖于其他一些宏，甚至可以在非 mt 变体中定义，因此将 mt 与非 mt 混合有时可以工作——但不要依赖于此。 )

至于性能损失 - 显然，mt 变体可能会慢一些。

更新：我对BOOST_HAS_THREADS appears to be wrong 的假设。尽管如此，混合 mt/非 mt 变体还是个坏主意，因为threading=multi 会影响 Boost ABI。