Why would you use a monitor instead of a semaphore?

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?

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.

StackExchange Computer Science Q#43721, answer score: 11