No, threading=multi并不意味着像 boost 容器这样的东西会突然变得可以安全地进行多个线程的并发访问（从性能的角度来看，这将是非常昂贵的）。
更确切地说，这意味着什么理论上boost 将被编译为线程感知。基本上，这意味着当从多个线程访问时，boost 方法和类将以合理的默认方式运行，就像 std 库中的类一样。这意味着您无法访问同一个物体从多个线程，除非另有说明，但您可以安全地从多个线程访问不同的对象。即使没有明确的支持，这似乎是显而易见的，但任何static如果不受到保护，库使用的状态将破坏该保证。使用threading=multi保证任何此类共享状态都是由互斥锁或其他机制保护的财产。
过去，类似的参数或 stdlib 风格可用于我的编译器提供的 C 和 C++ std 库，尽管现在大多只有多线程版本可用。
编译可能没有什么缺点threading=multi，假设只需要同步有限数量的静态。您的评论认为您的图书馆将mostly只被一个线程调用并不能激发很大的信心——毕竟，这些潜在的错误会导致你在喝了一晚上的酒后凌晨 3 点被老板叫醒。
boost的例子shared_ptr内容丰富。和threading=single，甚至不能保证两个的独立操纵shared_ptr来自多个线程的实例是安全的。如果它们碰巧指向同一个对象（或者，理论上，在某些奇异的实现下，即使它们没有），您将生成未定义的行为，因为共享状态不会通过适当的保护进行操作。
With threading=multi，这不会发生。然而，它仍然是not safe访问相同的shared_ptr来自多个线程的实例。也就是说，它不提供任何未针对相关对象记录的线程安全保证 - 但它确实提供了独立对象独立的“预期/合理/默认”保证。这种默认的线程安全级别没有一个好名字，但实际上它是当今多线程语言的所有标准库通常提供的。
最后一点，值得注意的是Boost.Thread总是隐式编译为threading=multi- 因为使用 boost 的多线程类是存在多个线程的隐式暗示。使用Boost.Thread没有多线程支持将是无意义的。
现在，综上所述，以上是编译 boost“带线程支持”或“不带线程支持”背后的理论思想，这就是threading=旗帜。实际上，自从引入此标志后，多线程已成为默认设置，而单线程则成为例外。事实上，许多默认为单线程行为的编译器和链接器现在默认为多线程 - 或者至少只需要一个“提示”（例如，命令行上存在 -pthread ）即可切换到多线程。
除此之外，我们还共同努力使 boost 构建变得“智能”——当环境有利时，它应该切换到多线程模式。这是相当模糊的，但必然如此。它变得与弱链接 pthreads 符号一样复杂，因此使用 MT 或 ST 代码的决定实际上推迟到运行时 - 如果 pthreads 在执行时可用，则将使用这些符号，否则弱链接存根 - 不执行任何操作根本-将被使用。
底线是threading=multi对于您的场景来说是正确且无害的，特别是如果您正在生成要分发到其他主机的二进制文件。如果你不特别的话，那就是极有可能由于构建时甚至运行时启发法，它无论如何都会起作用，但是您确实有机会默默地使用空存根方法，或者以其他方式使用 MT 不安全代码。使用正确的选项几乎没有什么缺点 - 但一些血淋淋的细节也可以在这一点的评论以及伊戈尔的回复中找到。
