问题描述
在我阅读的关于多线程的资源中，互斥量比信号量更常被使用和讨论。我的问题是什么时候使用信号量超过互斥？我在Boost线程中看不到信号量。这是不是意味着信号量不再使用很多这些天？
Throughout the resources I've read about multithreading, mutex is more often used and discussed compared to a semaphore. My question is when do you use a semaphore over a mutex? I don't see semaphores in Boost thread. Does that mean semaphores no longer used much these days?
据我所知，信号量允许资源被几个线程共享。这是唯一可能的，如果那些线程只读取资源，但不写。这是正确的吗？
As far as I've understand, semaphores allow a resource to be shared by several threads. This is only possible if those threads are only reading the resource but not writing. Is this correct?
推荐答案
Boost.Thread有互斥体和条件变量。纯粹在功能方面，信号量因此是多余的[*]，虽然我不知道这是为什么它们被省略。
Boost.Thread has mutexes and condition variables. Purely in terms of functionality, semaphores are therefore redundant[*], although I don't know if that's why they're omitted.
semaphores是一个更基本的原语，更简单，并且可能实现为更快，但不具有优先级反转避免。它们可能比条件变量更难使用，因为它们需要客户端代码来确保帖子的数量以某种适当的方式匹配等待的数量。使用条件变量很容易容忍虚假的帖子，因为没有人实际上 没有检查条件。
Semaphores are a more basic primitive, simpler, and possibly implemented to be faster, but don't have priority-inversion avoidance. They're arguably harder to use than condition variables, because they require the client code to ensure that the number of posts "matches" the number of waits in some appropriate way. With condition variables it's easy to tolerate spurious posts, because nobody actually does anything without checking the condition.
读取和写入资源是一个红色herring IMO，它与互斥体和信号量之间的区别无关。如果使用计数信号量，您可能会遇到多个线程并发访问同一资源的情况，在这种情况下，它可能必须是只读访问。在这种情况下，您可以使用Boost.Thread中的 shared_mutex 。但是信号量不是以互斥的方式保护资源，它们是用于从一个线程发送信号到另一个线程。可以使用来控制对资源的访问。
Read vs. write resources is a red herring IMO, it has nothing to do with the difference between a mutex and a semaphore. If you use a counting semaphore, you could have a situation where multiple threads are concurrently accessing the same resource, in which case it would presumably have to be read-only access. In that situation, you might be able to use shared_mutex from Boost.Thread instead. But semaphores aren't "for" protecting resources in the way mutexes are, they're "for" sending a signal from one thread to another. It's possible to use them to control access to a resource.
这并不意味着所有对信号量的使用都必须与只读资源。例如，您可以使用二进制信号量来保护读/写资源。可能不是一个好主意，虽然，因为互斥往往给你更好的调度行为。
That doesn't mean that all uses of semaphores must relate to read-only resources. For example, you can use a binary semaphore to protect a read/write resource. Might not be a good idea, though, since a mutex often gives you better scheduling behaviour.
[*]这里大致如何实现计数信号量使用互斥和条件变量。要实现一个共享信号量当然你需要一个共享的互斥量/ condvar：
[*] Here's roughly how you implement a counting semaphore using a mutex and a condition variable. To implement a shared semaphore of course you need a shared mutex/condvar:
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);
因此，任何你可以用信号量做，你可以做互斥和条件变量。不一定是通过实际实现信号量。
Therefore, anything you can do with semaphores, you can do with mutexes and condition variables. Not necessarily by actually implementing a semaphore, though.
这篇关于在什么情况下，在C ++中的互斥体上使用信号量？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！