1. Estructura e implementación:
* semáforos:
* variables enteras simples: En su núcleo, los semáforos son variables enteros a las que se accede y se modifican utilizando operaciones atómicas.
* Dos operaciones atómicas: Normalmente tienen dos operaciones principales:
* `Wait ()` (o `p ()` o `adquirir ()`):disminuye el valor semáforo. Si el valor se vuelve negativo, el proceso/hilo se bloquea hasta que el valor semáforo sea mayor o igual a cero.
* `Signal ()` (o `v ()` o `Release ()`):incrementa el valor de semáforo. Si hay procesos/hilos bloqueados que esperan en el semáforo, uno de ellos está desbloqueado.
* Sin asociación de datos implícitos: Los semáforos no unen inherentemente el mecanismo de sincronización a ningún datos específicos. Puede usar un semáforo para controlar el acceso a cualquier recurso compartido, pero debe administrar la asociación manualmente.
* monitores:
* Enfoque estructurado: Los monitores son construcciones de programación más estructuradas. Ellos encapsulan:
* Datos compartidos: Variables que representan el recurso compartido que está protegido.
* Procedimientos/Métodos: Las operaciones que acceden y modifican los datos compartidos. Estas son las únicas rutinas que pueden acceder directamente a los datos compartidos.
* Variables de condición: (¡Importantes!) Variables especiales utilizadas para la señalización y la espera dentro del monitor.
* Exclusión mutua explícita: Los monitores proporcionan una exclusión mutua implícita. Solo un hilo/proceso puede estar activo * dentro * del monitor en cualquier momento dado. Esta exclusión mutua se aplica automáticamente por el monitor.
2. Aplicación de la exclusión mutua:
* semáforos:
* Aplicación manual: Los semáforos dependen de los programadores para usar correctamente las operaciones `Wait ()` y `Signal ()` en torno a secciones críticas. Depende del programador garantizar que la exclusión mutua se mantenga adecuadamente. Los errores se pueden introducir fácilmente. Por ejemplo, olvidar una `señal ()` puede conducir a un punto muerto. Colocar `esperar ()` o `señal ()` fuera de la sección crítica prevista puede causar problemas de concurrencia.
* Error Presone: Esta aplicación manual es propensa a los errores. Es fácil cometer errores que rompen la exclusión mutua o causan muertos muertos.
* monitores:
* Aplicación implícita: Los monitores hacen cumplir la exclusión mutua *implícitamente *. El lenguaje/sistema asegura que solo un hilo pueda estar activo dentro del monitor a la vez. Esto hace que sea más fácil razonar y menos propenso a los errores. El compilador o el sistema de tiempo de ejecución maneja el bloqueo y el desbloqueo.
3. Sincronización de condición (espera y señalización):
* semáforos:
* De propósito general, pero menos estructurado para la espera de la condición: Los semáforos * se pueden * usarse para la sincronización de la condición (por ejemplo, esperar que haya un recurso disponible). Sin embargo, es un poco engorroso. Por lo general, necesita semáforos separados para la exclusión mutua y para las condiciones de señalización, lo que hace que el código sea más complejo y propenso al error. Puede usar semáforos de conteo para indicar cuántos de un recurso están disponibles.
* monitores:
* Variables de condición: Los monitores usan * Variables de condición * específicamente para la sincronización de la condición. Estos proporcionan operaciones como:
* `Espera (condición)`:El subproceso de llamada libera el bloqueo del monitor y espera en la 'condición' especificada. El hilo se coloca en una cola asociada con esa variable de condición. El bloqueo del monitor se libera para que otros subprocesos puedan ingresar al monitor.
* `Señal (condición)`:Se despierta un hilo que espera en la 'condición' especificada. La rosca señalada vuelve a adquirir el bloqueo del monitor.
* `Broadcast (condición)` (o `señalall (condición)`):despierta todos los hilos que esperan en la 'condición' especificada.
* Estructura mejorada: Las variables de condición están estrechamente vinculadas al monitor y sus datos compartidos, lo que hace que sea más fácil entender y razonar sobre la sincronización de la condición dentro del monitor.
4. Propiedad y responsabilidad:
* semáforos:
* No hay propiedad clara: Cualquier hilo puede `esperar ()` o `señal ()` en un semáforo. No hay concepto de "poseer" un semáforo.
* monitores:
* Propiedad clara: Los subprocesos deben ingresar al monitor (adquirir implícitamente el bloqueo del monitor) antes de acceder a los datos compartidos o las variables de condición de señalización. Esto impone un modelo de propiedad claro.
5. Reentrance:
* semáforos:
* No hay concepto inherente de reingreso: Los semáforos no saben si el hilo que llama `wait ()` o `señal ()` ya contiene el semáforo. Usando un semáforo reentrantemente (por ejemplo, el mismo hilo adquiere el semáforo varias veces sin liberarlo) puede conducir fácilmente a un punto muerto.
* monitores:
* Generalmente no reentrante: Los monitores generalmente están diseñados para ser *no reentrantes *. Un hilo que ya contiene el bloqueo del monitor no puede volver a ingresar al monitor. Esto simplifica el razonamiento sobre el estado del programa, pero a veces puede requerir código de reestructuración. Algunas implementaciones del monitor admiten la reingreso, pero es menos común.
En resumen:
| Característica | Semáforos | Monitores |
| ------------------- | --------------------------------------------- | -------------------------------------------------------------- |
| Estructura | Variables enteras simples | Construcción estructurada con datos, procedimientos y variables de condición |
| Exclusión mutua | Manual (responsabilidad del programador) | Implícito (aplicado por el monitor en sí) |
| Sincronización de condición | Se puede usar, pero menos estructurado | Explícito con variables de condición (espera, señal, transmisión) |
| Error propenso | Más propenso a errores debido a la gestión manual | Menos propenso a errores debido a la aplicación implícita |
| Propiedad | Sin propiedad clara | Propiedad clara (el hilo debe ingresar al monitor) |
| Reentrance | Generalmente no considerado | Generalmente no reentrante |
Cuándo usar cuál:
* semáforos: Aunque aún son valiosos, los semáforos a menudo se ven como un primitivo de nivel inferior. Son útiles cuando se necesita un mecanismo de conteo simple, o cuando los requisitos de sincronización son muy básicos. También son útiles en los sistemas donde los monitores no son compatibles de forma nativa.
* monitores: Se prefieren monitores cuando se trata de escenarios de sincronización más complejos. Su enfoque estructurado, exclusión mutua implícita y variables de condición hacen que sea más fácil escribir un código concurrente correcto y mantenible. Los monitores son adecuados para proteger las estructuras de datos compartidas e implementar patrones de sincronización. Muchos lenguajes de programación modernos proporcionan soporte incorporado para monitores o construcciones similares (por ejemplo, la palabra clave `sincronizada` de Java y` Wait () `,` notify () `,` notifyAll () `Métodos o 'Threading.lock`' de Python y 'threading.Condition`).
Ejemplo (Conceptual - No es un lenguaje específico):
Ejemplo de semáforo (conceptual):
`` `` ``
semáforo mutex =1; // semáforo binario para exclusión mutua
Semaphore ResourceAvailable =0; // Contando semáforo para los recursos disponibles
// hilo 1 (productor)
esperar (mutex);
// Acceda y modifica el recurso compartido
// Agregar recurso
señal (mutex);
señal (recursos de recursos); // señala que ahora hay un recurso disponible
// hilo 2 (consumidor)
esperar (recursos de recursos); // esperar a que un recurso esté disponible
esperar (mutex);
// Acceda y modifica el recurso compartido
// Consume el recurso
señal (mutex);
`` `` ``
Ejemplo de monitor (conceptual):
`` `` ``
monitor de mymonitor {
Datos compartidos:...;
condición de recursos de recursos;
método accessresource () {
// adquirir implícitamente el bloqueo del monitor
while (el recurso no está disponible) {
esperar (recursos de recursos); // Libere el bloqueo del monitor, espere en condición
}
// Acceda y modifica los datos compartidos
// ...
señal (recursos de recursos); // hilo de espera de señalización
// Libere implícitamente el bloqueo del monitor cuando el método regrese
}
Método AddResource () {
// adquirir implícitamente el bloqueo del monitor
// Agregar recurso a los datos compartidos
señal (recursos de recursos); // hilo de espera de señalización
// Libere implícitamente el bloqueo del monitor
}
}
`` `` ``
En el ejemplo del monitor, el monitor maneja automáticamente la exclusión mutua, por lo que es menos propensa a los errores. Las variables de condición proporcionan una forma más estructurada de manejar la espera y la señalización en comparación con el uso de semáforos directamente para este propósito.