versiones ultima sistemas servidores operativos logotipo licencia distribuciones años unix comparison posix semaphore tradeoff

sistemas - ultima version de unix



Diferencias entre los semáforos de System V y Posix (4)

De O''Reilly :

  • Una diferencia notable entre las implementaciones de semáforos de System V y POSIX es que en System V puede controlar cuánto se puede aumentar o disminuir el conteo de semáforos; mientras que en POSIX, el conteo de semáforos aumenta y disminuye en 1.
  • Los semáforos POSIX no permiten la manipulación de permisos de semáforo, mientras que los semáforos System V le permiten cambiar los permisos de los semáforos a un subconjunto del permiso original.
  • La inicialización y creación de semáforos es atómica (desde la perspectiva del usuario) en semáforos POSIX.
  • Desde una perspectiva de uso, los semáforos del Sistema V son torpes, mientras que los semáforos POSIX son directos
  • La escalabilidad de los semáforos POSIX (usando semáforos sin nombre) es mucho más alta que los semáforos del Sistema V. En un escenario de usuario / cliente, donde cada usuario crea sus propias instancias de un servidor, sería mejor usar semáforos POSIX.
  • Los semáforos del Sistema V, al crear un objeto de semáforo, crean una matriz de semáforos mientras que los semáforos POSIX crean solo uno. Debido a esta característica, la creación de semáforos (huella de memoria) es más costosa en los semáforos del Sistema V en comparación con los semáforos POSIX.
  • Se ha dicho que el rendimiento de los semáforos POSIX es mejor que los semáforos basados ​​en el Sistema V.
  • Los semáforos POSIX proporcionan un mecanismo para semáforos en todo el proceso en lugar de semáforos en todo el sistema. Entonces, si un desarrollador se olvida de cerrar el semáforo, al salir del proceso se limpia el semáforo. En términos simples, los semáforos POSIX proporcionan un mecanismo para semáforos no persistentes.

¿Cuáles son las ventajas y desventajas entre usar un sistema V y un semáforo de Posix?


Dos problemas principales con semáforos POSIX compartidos / nombrados utilizados en procesos separados (no hilos): los semáforos POSIX no proporcionan ningún mecanismo para activar un proceso de espera cuando un proceso diferente muere mientras se mantiene un bloqueo de semáforo. Esta falta de limpieza puede conducir a semáforos zombies que provocarán que cualquier otro proceso posterior que intente usarlos se estanque. Tampoco existe una forma POSIX de listar los semáforos en el sistema operativo para intentar identificarlos y limpiarlos. La sección POSIX en SysV IPC especifica las herramientas ipcs e ipcrm para listar y manipular los recursos globales de SysV IPC. No se especifican tales herramientas o incluso mecanismos para POSIX IPC, aunque en Linux estos recursos a menudo se pueden encontrar en / shm. Esto significa que una señal KILL al proceso incorrecto en el momento incorrecto puede bloquear un sistema completo de procesos que interactúan hasta que se reinicie.

Otra desventaja es el uso de la semántica de archivos para los semáforos POSIX. La implicación es que puede haber más de un semáforo compartido con el mismo nombre, pero en diferentes estados. Por ejemplo, un proceso llama a sem_open, luego a sem_unlink antes de sem_close. Este proceso aún puede usar el semáforo tal como desvincular un archivo abierto antes de cerrarlo. El proceso 2 llama a sem_open en el mismo semáforo entre las llamadas sem_unlink y sem_close del proceso 1, y (de acuerdo con la documentación) obtiene un nuevo semáforo con el mismo nombre, pero en un estado diferente que el proceso 1. Dos semáforos compartidos con el mismo nombre operar independientemente derrota el propósito de los semáforos compartidos.

La limitación anterior hace que los semáforos compartidos POSIX no se puedan utilizar en un sistema del mundo real sin la garantía de que nunca se pueden enviar señales imposibles de capturar. La limitación dos se puede mitigar mediante una codificación cuidadosa, asumiendo el control de todo el código que utilizará un semáforo determinado. Francamente, es más que sorprendente que hayan llegado al estándar como lo hacen.


Me pregunto qué hace que las personas diseñen API malas como System V Semaphores . Si tiene razones muy importantes para usar los semáforos del Sistema V (como las operaciones atómicas con múltiples incrementos y disminuciones en un solo paso), debe seguir con los semáforos denominados POSIX.

El artículo vinculado analiza lo que está mal y no es intuitivo con System V Semaphores.


Sé que esto es antiguo, pero para el beneficio de aquellos que siguen leyendo esta cortesía de Google, la razón número 1 que encuentro para usar los semáforos System V sobre semáforos POSIX (nivel de sistema) es la capacidad de adquirir el recurso de semáforo de una manera que es devuelto automáticamente por el kernel NO IMPORTA CÓMO SE EXTIENDE EL PROCESO.

Estoy de acuerdo en que las operaciones de semáforos múltiples (atómicas) rara vez se usan (aunque pueden ser útiles durante la puesta en escena), y que la interfaz System V es extraña, pero simplemente no hay forma de lograr confiablemente la misma semántica de limpieza con los semáforos POSIX.