我在多个地方读到 Boost.Signals 不是线程安全的，但我没有找到更多关于它的详细信息。这个简单的引用并没有说太多。现在大多数应用程序都有线程——即使它们尝试使用单线程，它们的一些库也可能使用线程（例如 libsdl）。
我猜该实现没有其他线程不访问该插槽的问题。所以从这个意义上说，它至少是线程安全的。
但究竟什么行得通，什么行不通？只要我不同时访问它，从多个线程中使用它会起作用吗？即，如果我在插槽周围建立自己的互斥锁？
或者我是否被迫仅在我创建它的那个线程中使用该插槽？或者我第一次使用它的地方？
我认为这也不太清楚，其中一位图书馆评论家在这里说：
我也不喜欢“线程”这个词只被命名了三遍的事实。Boost.signals2 希望成为一个“线程安全信号”库。因此，应该向用户提供有关该领域的更多细节，尤其是更多示例。
弄清楚它的一种方法是去源头看看他们使用 _mutex / lock() 来保护什么。然后想象一下如果没有这些电话会发生什么。:)
据我所知，它确保了简单的事情，例如“如果一个线程正在连接或断开连接，这不会导致另一个线程在迭代连接到这些信号的插槽时崩溃”。有点像使用 C 运行时库的线程安全版本如何确保如果两个线程同时进行有效调用，printf则不会发生崩溃。 （并不是说你将得到的输出有任何意义——你仍然要对高阶语义负责。）
它似乎不像 Qt，其中某个插槽的代码运行的线程是基于目标插槽的“线程亲和性”（这意味着发出信号可以触发许多不同线程上的插槽并行运行。）但我想不支持这就是为什么 boost::signal “组合器”可以做这样的事情。
我看到的一个问题是一个线程可以在另一个线程发出信号时连接或断开连接。
您可以轻松地包装信号并使用互斥锁连接呼叫。但是，包装连接并非易事。（connect 返回可用于断开连接的连接）。