我在多个地方读到Boost.Signals不是线程安全但我没有找到更多关于它的细节。这个简单的引用并没有说真的那么多。现在大多数应用程序都有线程 - 即使它们尝试使用单线程，它们的一些库也可能使用线程（例如libsdl）。
我想实现没有其他线程无法访问插槽的问题。所以在这个意义上它至少是线程安全的。
但是究竟什么有效，哪些无效？只要我不同时访问它，它是否可以在多个线程中使用它？即如果我在插槽周围建立自己的互斥锁？
或者我只是在我创建它的那个帖子中被迫使用插槽？或者我第一次使用它的地方？
答案 0 :(得分：5)
我认为它也不太清楚，其中一位图书馆审稿人said here：
我也不喜欢只有三次'thread'这个词被命名的事实。 Boost.signals2希望成为一个“线程安全信号”库。因此更多 应该给出细节，特别是关于该领域的更多例子 用户。
解决问题的一种方法是go to the source并查看他们使用_mutex / lock（）来保护它们。然后想象一下，如果那些电话不存在会发生什么。 :)
从我可以收集的内容来看，它确保简单的事情，例如“如果一个线程正在进行连接或断开连接，那么不会导致不同的线程迭代通过连接到这些信号的插槽崩溃”。有点像使用线程安全版本的C运行时库如何确保如果两个线程同时对printf进行有效调用，则不会发生崩溃。 （更不用说你得到的输出会有任何意义 - 你仍然要负责更高阶的语义。）
它似乎不像Qt，其中某个槽的代码运行的线程是基于目标槽的“线程关联”（这意味着发出信号可以触发许多不同线程上的槽来运行并行。）但我想不支持这就是为什么boost :: signal“combiners”可以do things like this。
答案 1 :(得分：0)
我看到的一个问题是，当另一个线程发出信号时，一个线程可以连接或断开连接。
您可以轻松包装信号并使用互斥锁连接来电。但是，包装连接并非易事。 （connect返回可用于断开连接的连接。）