为什么要使用监视器而不是信号灯？

我目前正在上大学的并行编程课程，最近我们开始谈论监视器的概念。虽然我了解相互排斥的必要性，但我不明白为什么要为此使用监视器。

据我了解，监视器可以确保在关键时刻始终只有一个或没有进程。我们可以使用信号量来实现这一目标。此外，我们使用信号量来实现监视器（或至少一种实现它们的可能性）。

那么，为什么我要实现与带有信号量的信号量完全相同的东西呢？我可以获得什么好处？

它们几乎是可以互换的，一个可以在另一个的基础上构建。它在某种程度上取决于所实施/首选的语言（例如Java具有使用“ synchronize”关键字的内置监视器）。但是，由于以下原因和区别，该信号量被认为是比监视器“低级”的实体：

Monitor和Semaphores都用于同一目的-线程同步。但是，监视器比信号量更易于使用，因为它们处理锁获取和释放的所有细节。使用信号量的应用程序必须释放在应用程序终止时线程已获取的所有锁-这必须由应用程序本身完成。如果应用程序不执行此操作，则任何需要共享资源的其他线程将无法继续。

使用信号量时的另一个区别是，访问共享资源的每个例程都必须在使用资源之前显式获取一个锁。在编写处理多线程的例程时，很容易忘记这一点。监视器与信号量不同，它会自动获取必要的锁。[1]

另请参阅极受好评的Stack Overflow答案Semaphore与Monitors-有什么区别？与公共厕所和自行车停放架的相似之处令人难忘。

我们最终讨论了今天为什么在讲座中使用监视器而不是信号灯。

基本上可以归结为：监视器和信号灯具有同等的表现力，这意味着您可以找到监视器的问题解决方案，该监视器最初使用了信号灯，反之亦然。

好吧，我们已经知道了，那么为什么要使用监视器而不是信号灯？

个人喜好。通常，桌面应用程序将使用监视器，从而减少了出错的可能性，但作为一种折衷，它具有相对膨胀的结构。另一方面，信号量通常用于操作系统中，因为它们是轻量级的结构，但错误的可能性更大。

我想我们可以得出结论，无论您是否需要/想要使用监视器或信号灯，这都是一个情况决定。如果构建实时系统，则可能需要使用信号灯；如果构建办公程序，则可能还需要使用监视器。

看看例如“ sempaphores的小书”艾伦·唐尼（Allen B. 它指出并解决了许多同步问题。尤其检查一下拙劣的解决方案，您会发现信号量是一种非常低级的机制，功能非常强大，但极易被滥用，在这种情况下，简单的错误会带来严重的后果（由于并发程序固有的不确定性操作，情况更加糟糕）。例如，很容易忘记强制执行互斥，操作错误的信号灯等。监视器为最常用的情况提供了预包装的解决方案，并具有面向对象编程的大多数优点（即，您知道弄乱监视器所管理的变量的唯一方法是通过其操作）。缺点是无法轻易将其改编成非面向对象的语言，