A nivel teórico, no son semánticamente diferentes. Puede implementar un mutex utilizando semáforos o viceversa (vea aquí un ejemplo). En la práctica, la implementación es diferente y ofrecen servicios ligeramente diferentes.
La diferencia práctica (en términos de los servicios del sistema que los rodean) es que la implementación de un mutex tiene como objetivo ser un mecanismo de sincronización más liviano. En oracle-speak, los mutex se conocen como pestillos y los semáforos se conocen como esperas .
En el nivel más bajo, utilizan algún tipo de prueba atómica y mecanismo de ajuste . Esto lee el valor actual de una ubicación de memoria, calcula algún tipo de condicional y escribe un valor en esa ubicación en una sola instrucción que no se puede interrumpir . Esto significa que puede adquirir un mutex y probar para ver si alguien más lo tuvo antes que usted.
Una implementación típica de mutex tiene un proceso o subproceso que ejecuta la instrucción test-and-set y evalúa si algo más ha establecido el mutex. Un punto clave aquí es que no hay interacción con el planificador , por lo que no tenemos idea (y no me importa) quién ha establecido el bloqueo. Luego, renunciamos a nuestro intervalo de tiempo e intentamos nuevamente cuando la tarea se reprograma o ejecutamos un spin-lock . Un bloqueo de giro es un algoritmo como:
Count down from 5000:
i. Execute the test-and-set instruction
ii. If the mutex is clear, we have acquired it in the previous instruction
so we can exit the loop
iii. When we get to zero, give up our time slice.
Cuando terminemos de ejecutar nuestro código protegido (conocido como sección crítica ), simplemente establecemos el valor de mutex en cero o lo que sea 'claro'. Si varias tareas intentan adquirir el mutex, la siguiente tarea que se programe después de que se libere el mutex tendrá acceso al recurso. Por lo general, usaría mutexes para controlar un recurso sincronizado donde el acceso exclusivo solo es necesario por períodos muy cortos de tiempo, normalmente para actualizar una estructura de datos compartida.
Un semáforo es una estructura de datos sincronizada (típicamente usando un mutex) que tiene un conteo y algunos contenedores de llamadas del sistema que interactúan con el planificador en un poco más de profundidad que las bibliotecas mutex. Los semáforos se incrementan y disminuyen y se usan para bloquear tareas hasta que algo más esté listo. Vea el problema del productor / consumidor para un ejemplo simple de esto. Los semáforos se inicializan a algún valor: un semáforo binario es solo un caso especial en el que el semáforo se inicializa a 1. La publicación en un semáforo tiene el efecto de despertar un proceso de espera.
Un algoritmo de semáforo básico se ve así:
(somewhere in the program startup)
Initialise the semaphore to its start-up value.
Acquiring a semaphore
i. (synchronised) Attempt to decrement the semaphore value
ii. If the value would be less than zero, put the task on the tail of the list of tasks waiting on the semaphore and give up the time slice.
Posting a semaphore
i. (synchronised) Increment the semaphore value
ii. If the value is greater or equal to the amount requested in the post at the front of the queue, take that task off the queue and make it runnable.
iii. Repeat (ii) for all tasks until the posted value is exhausted or there are no more tasks waiting.
En el caso de un semáforo binario, la principal diferencia práctica entre los dos es la naturaleza de los servicios del sistema que rodean la estructura de datos real.
EDITAR: como evan ha señalado correctamente, los spinlocks ralentizarán una máquina con un solo procesador. Solo usaría un spinlock en una caja multiprocesador porque en un solo procesador el proceso que contiene el mutex nunca lo restablecerá mientras se esté ejecutando otra tarea. Los Spinlocks solo son útiles en arquitecturas multiprocesador.