Why would you use a monitor instead of a semaphore?

Question

I am currently attending the concurrent programming course in my university and we recently started talking about the concept of a monitor. While I understand the necessity of mutual exclusion, I do not understand why I would use a monitor for that.

As I understand it, a monitor guarantees that exactly one or no process is in the critical section at all times. We can achieve exactly that with a semaphore. Furthermore we implement monitors (or at least one possibility to implement them is) with semaphores.

So why would I implement something that does exactly the same thing as a semaphore with a semaphore? What benefits do I get?

Answer 1

They are nearly interchangeable and one can be built out of the other. It is somewhat language dependent which is implemented/ preferred (eg Java has built-in monitors using "synchronize" keyword). However the semaphore is considered a "lower level" entity than the monitor for the following reasons & differences:

Both Monitors and Semaphores are used for the same purpose – thread synchronization. But, monitors are simpler to use than semaphores because they handle all of the details of lock acquisition and release. An application using semaphores has to release any locks a thread has acquired when the application terminates – this must be done by the application itself. If the application does not do this, then any other thread that needs the shared resource will not be able to proceed.

Another difference when using semaphores is that every routine accessing a shared resource has to explicitly acquire a a lock before using the resource. This can be easily forgotten when coding the routines dealing with multithreading . Monitors, unlike semaphores, automatically acquire the necessary locks.[1]

See also the highly voted Stack Overflow answer Semaphore vs. Monitors - what's the difference? with a great/ memorable analogy to public toilets & bike stands.

Answer 2

We finally discussed why you would use a monitor instead of a semaphore in the lecture today.

It basically comes down to this: The monitor and the semaphore are equally expressive, meaning you can find a solution for a problem with a monitor where originally a semaphore was used and vice versa.

Well, we already knew that, so why would you use a monitor instead of a semaphore?

Personal preference. Normally a desktop application would use monitors, leaving less possibilities for mistakes, but, as a trade off, having a relativly bloated structure. Semaphores on the other hand are often used in operating systems, as they are a lightweight structure, but leaving more possibilities for mistakes.

I guess we can conclude that it is a situational decision wether or not you need/want to use a monitor or a semaphore. If you build a real time system you might want to go with a semaphore, if you are building an office programm you might aswell go with a monitor.

Answer 3

Take a peek at e.g. "The little book of sempaphores" by Allen B. Downey. it states and solves lots of synchronization problems. Check particularly the botched solutions, and you will see that semaphores are a very low-level mechaism, very powerful but extremely easy to misuse, where simple mistakes have terrible consecuences (made even worse by the inherent nondeterministic operation of concurrent programs). It is e.g. easy to forget enforcing mutual exclusion, operating on the wrong semaphore, and so on. Monitors offer prepackaged solutions to the most often used cases, and carry with them most of the advantages of object oriented programming (i.e., you know the only way to mess with the variables managed by the monitor is through it's operations). The disadvantage is that they can't be retrofitted easily into non-object-oriented languages, and plain object-oriented languages will leave their use optional.