¿Por qué usarías un monitor en lugar de un semáforo?

Actualmente estoy asistiendo al curso de programación concurrente en mi universidad y recientemente comenzamos a hablar sobre el concepto de monitor. Si bien entiendo la necesidad de la exclusión mutua, no entiendo por qué usaría un monitor para eso.

Según tengo entendido, un monitor garantiza que exactamente uno o ningún proceso esté en la sección crítica en todo momento. Podemos lograr exactamente eso con un semáforo. Además, implementamos monitores (o al menos una posibilidad para implementarlos es) con semáforos.

Entonces, ¿por qué debería implementar algo que hace exactamente lo mismo que un semáforo con un semáforo? ¿Qué beneficios obtengo?

Son casi intercambiables y uno se puede construir del otro. Depende un poco del idioma que se implemente / prefiera (por ejemplo, Java tiene monitores integrados que usan la palabra clave "sincronizar"). Sin embargo, el semáforo se considera una entidad de "nivel inferior" que el monitor por las siguientes razones y diferencias:

Tanto los monitores como los semáforos se usan para el mismo propósito: sincronización de subprocesos. Pero, los monitores son más simples de usar que los semáforos porque manejan todos los detalles de la adquisición y liberación de bloqueos. Una aplicación que utiliza semáforos debe liberar cualquier bloqueo que haya adquirido un subproceso cuando finaliza la aplicación; esto debe hacerlo la propia aplicación. Si la aplicación no hace esto, cualquier otro subproceso que necesite el recurso compartido no podrá continuar.

Otra diferencia al usar semáforos es que cada rutina que accede a un recurso compartido tiene que adquirir explícitamente un bloqueo antes de usar el recurso. Esto se puede olvidar fácilmente al codificar las rutinas que se ocupan de subprocesos múltiples. Los monitores, a diferencia de los semáforos, adquieren automáticamente los bloqueos necesarios. [1]

Vea también la respuesta altamente votada Stack Overflow Semaphore vs. Monitors: ¿cuál es la diferencia? con una gran / memorable analogía con baños públicos y soportes para bicicletas.

Finalmente discutimos por qué usarías un monitor en lugar de un semáforo en la conferencia de hoy.

Básicamente se trata de esto: el monitor y el semáforo son igualmente expresivos, lo que significa que puede encontrar una solución para un problema con un monitor donde originalmente se utilizó un semáforo y viceversa.

Bueno, eso ya lo sabíamos, ¿por qué usarías un monitor en lugar de un semáforo?

Preferencia personal. Normalmente, una aplicación de escritorio usaría monitores, dejando menos posibilidades de errores, pero, como compensación, tener una estructura relativamente hinchada. Los semáforos, por otro lado, a menudo se usan en los sistemas operativos, ya que son una estructura liviana, pero dejan más posibilidades de errores.

Supongo que podemos concluir que es una decisión situacional si necesita o no quiere usar un monitor o un semáforo. Si construye un sistema en tiempo real, es posible que desee ir con un semáforo, si está construyendo un programa de oficina, también puede ir con un monitor.

Eche un vistazo a, por ejemplo, "El pequeño libro de los semáforos"por Allen B. Downey. establece y resuelve muchos problemas de sincronización. Verifique particularmente las soluciones fallidas, y verá que los semáforos son un mecanismo de muy bajo nivel, muy poderoso pero extremadamente fácil de usar, donde los errores simples tienen consecuencias terribles (empeoradas aún más por la operación inherente no determinista de los programas concurrentes). Por ejemplo, es fácil olvidar imponer la exclusión mutua, operar en el semáforo incorrecto, etc. Los monitores ofrecen soluciones preempaquetadas para los casos más utilizados y llevan consigo la mayoría de las ventajas de la programación orientada a objetos (es decir, usted sabe que la única forma de meterse con las variables administradas por el monitor es a través de sus operaciones). La desventaja es que no se pueden adaptar fácilmente a lenguajes no orientados a objetos,