c++ - 编译 boost 时 `threading=multi` 到底做了什么？

Question

我不完全确定 threading=multi 到底是什么flag 在构建 boost 时会做。文档说:

 Causes the produced binaries to be thread-safe. This requires proper
 support in the source code itself.

这似乎不是很具体。这是否意味着访问，例如，boost 容器由 mutexes/locks 保护？或类似？由于我的代码的性能至关重要，我想尽量减少任何不必要的互斥等。

更多细节:

我的代码是一个插件 DLL，它被加载到一个多线程的第三方应用程序中。我将 boost 静态链接到 DLL(除了标准 Windows DLL 外，不允许插件具有任何其他依赖项，因此我被迫这样做)。

尽管该应用程序是多线程的，但我的 DLL 中的大多数函数只能从单个线程调用，因此不需要保护对容器的访问。我通过使用 boost::mutex 明确地保护了我的代码的剩余位置，这些位置可以从多个线程中调用。和 friend 。

我试过用 threading=multi 来构建 boost 和 threading=single两者似乎都有效，但我真的很想知道我在这里做什么。

Answer 1

不，threading=multi并不意味着像 boost 容器这样的东西对于多线程并发访问会突然变得安全(从性能的角度来看，这将是非常昂贵的)。

相反，它在理论上意味着 boost 将被编译为线程感知。基本上这意味着当从多个线程访问时，boost 方法和类将以合理的默认方式运行，就像 std 库中的类一样。这意味着您不能从多个线程访问同一个对象，除非另有说明，但您可以安全地从多个线程访问不同的对象。即使没有明确的支持，这似乎也很明显，但任何 static如果不 protected ，库使用的状态将破坏该保证。使用 threading=multi保证任何这样的共享状态都是由互斥锁或其他一些机制保护的属性。

过去，我的编译器提供的 C 和 C++ 标准库提供了类似的参数或标准库风格，尽管今天大多数情况下只有多线程版本可用。

使用 threading=multi 编译可能没有什么缺点，鉴于只需要同步有限数量的静态。你的评论说你的库大部分只会被一个线程调用并不能激发你的信心——毕竟，这些都是潜在的错误，会导致你在凌晨 3 点被老板在一个晚上后唤醒长期饮酒。

boost的例子shared_ptr是翔实的。与 threading=single ，甚至不能保证两个shared_ptr的独立操作来自多个线程的实例是安全的。如果它们碰巧指向同一个对象(或者，理论上，在一些奇特的实现下，即使它们没有)，您将生成未定义的行为，因为共享状态不会被适当的保护操作。

与 threading=multi ，这不会发生。然而，它仍然是不安全 访问相同的 shared_ptr来自多个线程的实例。也就是说，它没有提供任何未针对相关对象记录的线程安全保证 - 但它确实提供了独立对象独立的“预期/合理/默认”保证。这个默认的线程安全级别没有一个好名字，但实际上它是当今多线程语言的所有标准库。

最后一点，值得注意的是Boost.Thread总是用 threading=multi 隐式编译- 因为使用 boost 的多线程类是存在多个线程的隐式提示。使用 Boost.Thread没有多线程支持将是荒谬的。

现在，综上所述，以上是“有线程支持”或“无线程支持”编译 boost 背后的理论思想，这是 threading= 的目的。旗帜。在实践中，自从引入这个标志后，多线程成为默认，单线程成为异常(exception)。事实上，许多默认为单线程行为的编译器和链接器现在默认为多线程 - 或者至少只需要一个“提示”(例如，命令行上存在 -pthread)即可切换到多线程。

除此之外，还协同努力使 boost 构建变得“智能”——因为当环境有利于它时，它应该切换到多线程模式。这很模糊，但必然如此。它变得像弱链接 pthreads 符号一样复杂，因此使用 MT 或 ST 代码的决定实际上推迟到运行时 - 如果 pthreads 在执行时可用，则将使用这些符号，否则将使用弱链接 stub - 什么都不做在所有 - 将被使用。

底线是threading=multi对您的场景来说是正确且无害的，尤其是当您生成二进制文件时，您将分发给其他主机。如果您不特别注意，由于构建时甚至运行时启发式方法，它很可能无论如何都会工作，但是您确实有机会静默使用空 stub 方法，或以其他方式使用 MT 不安全代码。使用正确的选项几乎没有什么缺点——但一些血腥的细节也可以在评论中找到，Igor 的回复也是如此。