互斥体与监视器 - 比较
根据我对互斥锁的了解，它们通常提供对共享资源的锁定功能。因此，如果一个新线程想要访问这个锁定的共享资源，它要么退出，要么必须不断轮询锁（并在等待锁时浪费处理器周期）。
然而，监视器具有条件变量，它为等待线程提供了一种更加异步的方式 - 通过将它们放入等待队列，从而不使它们消耗处理器周期。
这是监视器相对于互斥体（或任何没有条件变量的通用锁定机制）的唯一优势吗？
From what I have learned about Mutexes - they generally provide a locking capability on a shared resources. So if a new thread wants to access this locked shared resource - it either quits or has to continually poll the lock (and wastes processor cycles in waiting for the lock).
However, a monitor has condition variables which provides a more asynchronous way for waiting threads - by putting them on wait queue and thereby not making them consume processor cycles.
Would this be the only advantage of monitors over mutexes (or any general locking mechanism without condition variables) ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
互斥体是低级构造。它们只是提供互斥和内存可见性/排序。另一方面，监视器是更高级别的 - 它们允许线程等待应用程序特定条件成立。
因此，在某些情况下，监视器对于简单的锁定/解锁来说太过分了，但在大多数情况下，仅使用互斥锁是不够的 - 因此您会看到它们与一个或多个条件变量一起使用 - 概念上使用等效的监视器。
Mutexes are low level construct. They just provide mutual exclusion and memory visibility/ordering. Monitors, on the other hand, are higher level - they allow threads to wait for an application specific condition to hold.
So, in some cases monitors are just overkill over a simple lock/unlock, but in most cases mutexes alone are not nearly enough - so you see them used with one or more condition variables - conceptually using monitors equivalent.
我认为，监视器锁定一个对象（多线程不能同时访问该对象。）
而互斥体锁定一个进程（多线程中只有一个可以通过该进程。）
I think, a monitor locks an object (Multi thread cannot access the object at the same time.)
While a mutex locks a process (multi-thread only one can go through the process.)