在什么情况下，在 C++ 中使用信号量而不是互斥锁？

Question

在我阅读的有关多线程的资源中，与信号量相比，互斥体的使用和讨论更为频繁。我的问题是什么时候使用信号量而不是互斥体？我在 Boost 线程中没有看到信号量。这是否意味着信号量如今不再被广泛使用？

据我所知，信号量允许多个线程共享资源。仅当这些线程仅读取资源而不写入资源时，这才有可能。这是正确的吗？

Answer 1

互斥体的典型用例（任何时候只允许一个线程访问资源）比信号量的典型用途更为常见。但信号量实际上是更通用的概念：互斥量（几乎）是信号量的特例。

典型的应用程序是： 您不想创建超过（例如）5 个数据库连接。无论有多少工作线程，它们都必须共享这5个连接。或者，如果您在 N 核计算机上运行，​​您可能需要确保某些 CPU/内存密集型任务不会同时在超过 N 个线程中运行（因为这只会因上下文切换而降低吞吐量）和缓存抖动效果）。您甚至可能希望将并行 CPU/内存密集型任务的数量限制为 N-1，这样系统的其余部分就不会挨饿。或者想象某个任务需要大量内存，因此同时运行该任务的 N 个以上实例将导致分页。您可以在此处使用信号量，以确保同时运行的特定任务的实例不超过 N 个。

编辑/PS：根据您的问题“只有当这些线程只读取资源而不写入资源时，这才有可能。这是正确的吗？”以及您的评论，在我看来，您似乎将资源视为变量或流，可以读取或写入，并且一次只能由一个线程写入。不。在这种情况下，这是误导性的。

将资源想象成“水”。您可以用水来洗碗。我可以同时用水来洗碗。我们不需要任何形式的同步，因为我们俩都有足够的水。我们不一定使用相同的水。 （而且你无法“读”或“写”水。）但是水的总量是有限的。因此任何人数的团体都不可能同时洗碗。这种同步是通过信号量完成的。只是通常不使用水，而是使用其他有限资源，如内存、磁盘空间、IO 吞吐量或 CPU 内核。

Answer 2

互斥体和信号量之间的本质区别与所有权的概念有关。当获取互斥体时，我们认为该线程拥有互斥体，并且该线程稍后必须释放互斥体以释放资源。

对于信号量，可以将信号量视为消耗资源，但实际上并不获取资源的所有权。这通常被称为信号量“空”而不是由线程拥有。那么信号量的特点是不同的线程可以将信号量“填充”回“满”状态。

因此，互斥体通常用于资源的并发保护（即：MUTual EXlusion），而信号量用于线程之间的信号传递（如船舶之间的信号量标志信号传递）。互斥体本身并不能真正用于信号发送，但信号量可以。因此，选择其中之一取决于您想要做什么。

请参阅另一个我的一个答案有关递归互斥体和非递归互斥体之间区别的相关主题的更多讨论。

Answer 3

控制对多个线程（进程间或进程内）共享的有限数量资源的访问。

在我们的应用程序中，我们拥有非常繁重的资源，并且我们不想为 M 个工作线程中的每一个分配一个资源。由于工作线程只需要其工作的一小部分资源，因此我们很少同时使用超过几个资源。

因此，我们分配了 N 个资源，并将它们放在初始化为 N 的信号量后面。当超过 N 个线程尝试使用该资源时，它们只会阻塞，直到有一个可用为止。

Answer 4

Boost.Thread 有互斥体和条件变量。纯粹就功能而言，信号量因此是多余的[*]，尽管我不知道这是否就是它们被省略的原因。

信号量是一种更基本的原语，更简单，并且可能实现得更快，但不具有优先级反转避免功能。它们可以说比条件变量更难使用，因为它们要求客户端代码以某种适当的方式确保帖子数量与等待数量“匹配”。使用条件变量，很容易容忍虚假帖子，因为没有人在不检查条件的情况下实际上做任何事情。

在我看来，读资源与写资源是一个转移注意力的话题，它与互斥锁和信号量之间的区别无关。如果您使用计数信号量，则可能会遇到多个线程同时访问同一资源的情况，在这种情况下，它可能必须是只读访问。在这种情况下，您也许可以使用 Boost.Thread 中的 shared_mutex 来代替。但信号量并不像互斥体那样“用于”保护资源，它们“用于”从一个线程向另一个线程发送信号。可以使用它们来控制对资源的访问。

这并不意味着信号量的所有使用都必须与只读资源相关。例如，您可以使用二进制信号量来保护读/写资源。不过，这可能不是一个好主意，因为互斥锁通常可以为您提供更好的调度行为。

[*] 下面大致介绍了如何使用互斥锁和条件变量来实现计数信号量。要实现共享信号量，您当然需要共享互斥体/条件变量：

struct sem {
    mutex m;
    condvar cv;
    unsigned int count;
};

sem_init(s, value)
    mutex_init(s.m);
    condvar_init(s.cv);
    count = value;

sem_wait(s)
    mutex_lock(s.m);
    while (s.count <= 0) {
        condvar_wait(s.cv, s.m);
    }
    --s.count;
    mutex_unlock(s.m);

sem_post(s)
    mutex_lock(s.m);
    ++s.count;
    condvar_broadcast(s.cv)
    mutex_unlock(s.m);

因此，您可以使用信号量执行的任何操作，都可以使用互斥体和条件变量执行。但不一定是通过实际实现信号量来实现。

Answer 5

我觉得没有简单的方法可以真正回答您的问题而不忽略有关信号量的一些重要信息。人们写了 很多关于信号量的书籍，所以任何一两段答案都是一种伤害。一本流行的书是The Little Book of Semaphores...适合那些不知道的人不喜欢大书:)。

这是一篇不错的长篇文章，其中详细介绍了如何使用信号量以及它们的用途。

更新：
丹指出了我的示例中的一些错误，我将留下参考文献，这些参考文献提供了比我的更好的解释:)。

以下参考资料展示了使用信号量的正确方法：
1. IBM 文章
2.芝加哥大学课堂讲座
3.我最初发布的 Netrino 文章。
4. “卖票”纸+代码。

Answer 6

摘自这篇文章< /a>:

互斥锁允许发生进程间同步。如果您使用名称实例化互斥锁（如上面的代码所示），则互斥锁将成为系统范围的。如果您在许多不同的应用程序之间共享同一个库，并且需要阻止对正在访问无法共享的资源的关键代码部分的访问，那么这非常有用。

最后是信号量类。假设您有一个真正占用 CPU 资源的方法，并且还利用了您需要控制访问的资源（使用互斥体:)）。您还确定，最多五次对该方法的调用几乎是您的机器可以处理的所有情况，而不会使其无响应。这里最好的解决方案是使用 Semaphore 类，它允许您限制一定数量的线程对资源的访问。

Answer 7

据我了解，信号量现在是一个与 IPC 密切相关的术语。它仍然意味着许多进程可以修改受保护的变量，但在进程之间并且操作系统支持此功能。

通常，我们不需要变量，一个简单的互斥体就可以满足我们的所有需求。如果我们仍然需要一个变量，可能我们自己编写代码 - “变量+互斥体”以获得更多控制。

简历：我们在多线程中不使用信号量，因为通常使用互斥量来简化和控制，并且我们在 IPC 中使用信号量，因为它是操作系统支持的，也是进程同步机制的正式名称。

Answer 8

信号量最初是为了跨进程同步而设计的。 Windows 使用类似于信号量的 WaitForMultipleObjects。在 Linux 世界中，最初的 pthread 实现不允许跨进程共享互斥体。现在他们做到了。在线程成为CPU调度单位之后，打破原子增量（Windows中的互锁增量）和轻量级互斥的概念是当今最实际的实现。如果增量和锁在一起（信号量），则获取/释放锁的时间将太长，并且我们无法像今天那样为了性能和更好的同步结构而拆分这两个单元函数。

Answer 9

根据我在大学学到的关于信号量和互斥量的知识，信号量更多的是理论对象，而互斥量是信号量的一种实现。考虑到这一点，信号量更加灵活。

互斥锁高度依赖于实现。它们已针对二进制锁定目的进行了优化。互斥体的正常用例是二进制信号量。

一般来说，当尝试编写无错误的多线程代码时，简单性会有所帮助。互斥锁的使用较多，因为它们的简单性有助于避免因使用信号量而出现的复杂死锁情况。