operating-system - semaforos - que es mutex en sistemas operativos

Diferencia entre semáforo binario y mutex. (29)

A nivel teórico, no son diferentes semánticamente. Puede implementar un mutex utilizando semáforos o viceversa (consulte here para ver 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 el lenguaje oráculo, los mutex se conocen como latches y los semáforos se conocen como waits .

En el nivel más bajo, usan algún tipo de prueba atómica y un 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 puede ser interrumpida . Esto significa que puede adquirir un mutex y realizar una prueba para ver si alguien más lo tuvo antes que usted.

Una implementación de exclusión mutua típica tiene un proceso o subproceso que ejecuta la instrucción de prueba y ajuste y evalúa si alguna otra cosa ha establecido la exclusión mutua. Un punto clave aquí es que no hay interacción con el scheduler , por lo que no tenemos idea (y no nos importa) quién ha establecido el bloqueo. Luego renunciamos a nuestro intervalo de tiempo y lo intentamos de nuevo cuando la tarea se vuelve a programar 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 hayamos terminado de ejecutar nuestro código protegido (conocido como una sección crítica ), simplemente establecemos el valor de exclusión mutua en cero o lo que sea que signifique "borrar". Si varias tareas intentan adquirir el mutex, la próxima tarea que se programe después de que se libere el mutex tendrá acceso al recurso. Por lo general, se usarían las exclusiones mutuas para controlar un recurso sincronizado donde el acceso exclusivo solo se necesita durante períodos muy cortos de tiempo, normalmente para actualizar una estructura de datos compartida.

Un semáforo es una estructura de datos sincronizada (que normalmente utiliza un mutex) que tiene un recuento y algunos envoltorios de llamadas del sistema que interactúan con el programador con un poco más de profundidad de lo que lo harían las bibliotecas mutex. Los semáforos se incrementan y disminuyen y se usan para block tareas hasta que algo más esté listo. Ver Problema del productor / consumidor para un ejemplo simple de esto. Los semáforos se inicializan con algún valor: un semáforo binario es solo un caso especial en el que el semáforo se inicializa en 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 parece a:

(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 la máquina de un solo procesador. Solo usaría un spinlock en una caja de multiprocesador porque en un solo procesador el proceso que mantiene el mutex nunca lo restablecerá mientras se ejecuta otra tarea. Los Spinlocks solo son útiles en arquitecturas multiprocesador.

¿Hay alguna diferencia entre un semáforo binario y un mutex o son esencialmente lo mismo?

Aparte del hecho de que los mutexes tienen un propietario, los dos objetos pueden optimizarse para diferentes usos. Los Mutexes están diseñados para ser mantenidos solo por un corto tiempo; violar esto puede causar un rendimiento deficiente y una programación injusta. Por ejemplo, se puede permitir que un subproceso en ejecución adquiera un mutex, incluso si otro subproceso ya está bloqueado en él. Los semáforos pueden proporcionar más equidad, o la equidad puede forzarse usando varias variables de condición.

Buenos artículos sobre el tema:

De la parte 2:

El mutex es similar a los principios del semáforo binario con una diferencia significativa: el principio de propiedad. La propiedad es el concepto simple de que cuando una tarea bloquea (adquiere) una exclusión mutua, solo puede desbloquearla (liberarla). Si una tarea intenta desbloquear un mutex, no se ha bloqueado (por lo tanto, no es de su propiedad), entonces se encuentra una condición de error y, lo más importante, el mutex no se desbloquea. Si el objeto de exclusión mutua no tiene propiedad entonces, independientemente de cómo se llame, no es un mutex.

Como ninguna de las respuestas anteriores aclara la confusión, aquí hay una que aclaró mi confusión.

En sentido estricto, un mutex es un mecanismo de bloqueo utilizado para sincronizar el acceso a un recurso. Solo una tarea (puede ser un subproceso o un proceso basado en la abstracción del sistema operativo) puede adquirir el mutex. Significa que habrá propiedad asociada con mutex, y solo el propietario puede liberar el bloqueo (mutex).
El semáforo es un mecanismo de señalización (tipo de señal "He terminado, puede continuar"). Por ejemplo, si está escuchando canciones (suponga que son una sola tarea) en su teléfono móvil y al mismo tiempo que su amigo lo llamó, se activará una interrupción sobre la cual una rutina de servicio de interrupción (ISR) indicará la tarea de procesamiento de llamadas para que se active. .

Fuente: http://www.geeksforgeeks.org/mutex-vs-semaphore/

Diferencia entre semáforo binario y exclusión mutua: PROPIEDAD: Los semáforos se pueden señalar (publicar) incluso desde un propietario que no es actual. Significa que simplemente puedes publicar desde cualquier otro hilo, aunque no seas el propietario.

Semaphore es una propiedad pública en proceso, puede ser simplemente publicada por un hilo no propietario. Por favor, marca esta diferencia en letras NEGRAS, significa mucho.

El concepto fue claro para mí después de revisar las publicaciones anteriores. Pero hubo algunas preguntas persistentes. Entonces, escribí este pequeño trozo de código.

Cuando intentamos dar un semáforo sin tomarlo, se pasa. Pero, cuando intentas dar un mutex sin tomarlo, falla. He probado esto en una plataforma de Windows. Habilite USE_MUTEX para ejecutar el mismo código usando un MUTEX.

#include <stdio.h> #include <windows.h> #define xUSE_MUTEX 1 #define MAX_SEM_COUNT 1 DWORD WINAPI Thread_no_1( LPVOID lpParam ); DWORD WINAPI Thread_no_2( LPVOID lpParam ); HANDLE Handle_Of_Thread_1 = 0; HANDLE Handle_Of_Thread_2 = 0; int Data_Of_Thread_1 = 1; int Data_Of_Thread_2 = 2; HANDLE ghMutex = NULL; HANDLE ghSemaphore = NULL; int main(void) { #ifdef USE_MUTEX ghMutex = CreateMutex( NULL, FALSE, NULL); if (ghMutex == NULL) { printf("CreateMutex error: %d/n", GetLastError()); return 1; } #else // Create a semaphore with initial and max counts of MAX_SEM_COUNT ghSemaphore = CreateSemaphore(NULL,MAX_SEM_COUNT,MAX_SEM_COUNT,NULL); if (ghSemaphore == NULL) { printf("CreateSemaphore error: %d/n", GetLastError()); return 1; } #endif // Create thread 1. Handle_Of_Thread_1 = CreateThread( NULL, 0,Thread_no_1, &Data_Of_Thread_1, 0, NULL); if ( Handle_Of_Thread_1 == NULL) { printf("Create first thread problem /n"); return 1; } /* sleep for 5 seconds **/ Sleep(5 * 1000); /*Create thread 2 */ Handle_Of_Thread_2 = CreateThread( NULL, 0,Thread_no_2, &Data_Of_Thread_2, 0, NULL); if ( Handle_Of_Thread_2 == NULL) { printf("Create second thread problem /n"); return 1; } // Sleep for 20 seconds Sleep(20 * 1000); printf("Out of the program /n"); return 0; } int my_critical_section_code(HANDLE thread_handle) { #ifdef USE_MUTEX if(thread_handle == Handle_Of_Thread_1) { /* get the lock */ WaitForSingleObject(ghMutex, INFINITE); printf("Thread 1 holding the mutex /n"); } #else /* get the semaphore */ if(thread_handle == Handle_Of_Thread_1) { WaitForSingleObject(ghSemaphore, INFINITE); printf("Thread 1 holding semaphore /n"); } #endif if(thread_handle == Handle_Of_Thread_1) { /* sleep for 10 seconds */ Sleep(10 * 1000); #ifdef USE_MUTEX printf("Thread 1 about to release mutex /n"); #else printf("Thread 1 about to release semaphore /n"); #endif } else { /* sleep for 3 secconds */ Sleep(3 * 1000); } #ifdef USE_MUTEX /* release the lock*/ if(!ReleaseMutex(ghMutex)) { printf("Release Mutex error in thread %d: error # %d/n", (thread_handle == Handle_Of_Thread_1 ? 1:2),GetLastError()); } #else if (!ReleaseSemaphore(ghSemaphore,1,NULL) ) { printf("ReleaseSemaphore error in thread %d: error # %d/n",(thread_handle == Handle_Of_Thread_1 ? 1:2), GetLastError()); } #endif return 0; } DWORD WINAPI Thread_no_1( LPVOID lpParam ) { my_critical_section_code(Handle_Of_Thread_1); return 0; } DWORD WINAPI Thread_no_2( LPVOID lpParam ) { my_critical_section_code(Handle_Of_Thread_2); return 0; }

En Windows, hay dos diferencias entre mutexes y semáforos binarios:

Un hilo mutex solo puede ser liberado por el subproceso que tiene la propiedad, es decir, el subproceso que anteriormente se llamaba la función Esperar (o que tomó la propiedad al crearlo). Un semáforo puede ser liberado por cualquier hilo.
Un hilo puede llamar una función de espera repetidamente en un mutex sin bloquear. Sin embargo, si llama a una función de espera dos veces en un semáforo binario sin liberar el semáforo intermedio, el hilo se bloqueará.

En windows la diferencia es la siguiente. MUTEX: el proceso que ejecuta con éxito la espera tiene que ejecutar una señal y viceversa. SEMAFORES BINARIOS: Diferentes procesos pueden ejecutar la operación de espera o señal en un semáforo.

La pregunta modificada es: ¿Cuál es la diferencia entre un mutex y un semáforo "binario" en "Linux"?

Respuesta: Las siguientes son las diferencias: i) Ámbito: el ámbito de exclusión mutua se encuentra dentro de un espacio de direcciones de proceso que lo ha creado y se utiliza para la sincronización de subprocesos. Mientras que el semáforo se puede usar en el espacio de proceso y, por lo tanto, se puede usar para la sincronización entre procesos.

ii) Mutex es ligero y más rápido que el semáforo. Futex es aún más rápido.

iii) Se puede adquirir Mutex por el mismo hilo con éxito varias veces con la condición de que se debe liberar el mismo número de veces. Otro hilo que intenta adquirir se bloqueará. Mientras que en el caso de un semáforo, si el mismo proceso intenta adquirirlo nuevamente, se bloquea, ya que solo se puede adquirir una vez.

La respuesta puede depender del sistema operativo de destino. Por ejemplo, al menos una implementación de RTOS con la que estoy familiarizado permitirá múltiples operaciones secuenciales de "obtención" contra un único mutex del sistema operativo, siempre que todas sean del mismo contexto de subproceso. Las entradas múltiples deben reemplazarse por un número igual de entradas antes de que otra hebra pueda obtener la exclusión mutua. Esto difiere de los semáforos binarios, para los cuales solo se permite una única obtención a la vez, independientemente de los contextos de subprocesos.

La idea detrás de este tipo de exclusión mutua es que protege un objeto permitiendo solo que un solo contexto modifique los datos a la vez. Incluso si el subproceso obtiene la exclusión mutua y luego llama a una función que modifica aún más el objeto (y obtiene / coloca la exclusión mutua protectora alrededor de sus propias operaciones), las operaciones deberían seguir siendo seguras, ya que todas están sucediendo bajo una única conexión.

{ mutexGet(); // Other threads can no longer get the mutex. // Make changes to the protected object. // ... objectModify(); // Also gets/puts the mutex. Only allowed from this thread context. // Make more changes to the protected object. // ... mutexPut(); // Finally allows other threads to get the mutex. }

Por supuesto, cuando use esta función, debe estar seguro de que todos los accesos dentro de un solo hilo son realmente seguros.

No estoy seguro de qué tan común es este enfoque, o si se aplica fuera de los sistemas con los que estoy familiarizado. Para ver un ejemplo de este tipo de exclusión mutua, consulte el RTOS de ThreadX.

Mientras que un semáforo binario se puede usar como mutex, un mutex es un caso de uso más específico, ya que solo el proceso que bloquea el mutex se supone que lo desbloquea. Esta restricción de propiedad hace posible proporcionar protección contra:

Lanzamiento accidental
Punto muerto recursivo
Deadlock de tarea

Estas restricciones no siempre están presentes porque degradan la velocidad. Durante el desarrollo de su código, puede habilitar estas comprobaciones temporalmente.

por ejemplo, puede habilitar el atributo Error check en su mutex. El error en la comprobación de EDEADLK devuelve EDEADLK si intenta bloquear la misma dos veces y EPERM si desbloquea una exclusión que no es suya.

pthread_mutex_t mutex; pthread_mutexattr_t attr; pthread_mutexattr_init (&attr); pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_ERRORCHECK_NP); pthread_mutex_init (&mutex, &attr);

Una vez inicializados podemos colocar estos chequeos en nuestro código así:

if(pthread_mutex_unlock(&mutex)==EPERM) printf("Unlock failed:Mutex not owned by this thread/n");

Mito:

Un par de artículos dice que "el semáforo binario y el mutex son iguales" o "El semáforo con el valor 1 es el mutex", pero la diferencia básica es que el Mutex solo puede ser liberado por el hilo que lo adquirió, mientras que puedes señalar el semáforo desde cualquier otro hilo.

Puntos clave:

• Un hilo puede adquirir más de un bloqueo (Mutex).

• Un mutex puede bloquearse más de una vez solo si es un mutex recursivo, aquí el bloqueo y desbloqueo para mutex debería ser el mismo

• Si un subproceso que ya había bloqueado un mutex, intenta bloquearlo nuevamente, entrará en la lista de espera de ese mutex, lo que resulta en un interbloqueo.

• El semáforo binario y el mutex son similares pero no iguales.

• Mutex es una operación costosa debido a los protocolos de protección asociados.

• El objetivo principal de mutex es lograr acceso atómico o bloquear recursos.

Mutex se usa para proteger el código y los datos confidenciales, el semáforo se usa para la sincronización. También puede tener un uso práctico con la protección del código sensible, pero puede haber un riesgo de que la otra hebra de protección se libere mediante la operación V.So La principal la diferencia entre bi-semáforo y mutex es la propiedad. Por ejemplo, por inodoro, Mutex es como que uno puede entrar al inodoro y cerrar la puerta, nadie más puede entrar hasta que el hombre salga, el bi-semáforo es como que uno puede entrar el inodoro y la puerta con llave, pero alguien más podría entrar al pedirle al administrador que abra la puerta, es ridículo.

Mutex se utilizan para "Mecanismos de bloqueo". Un proceso a la vez puede usar un recurso compartido.

mientras

Los semáforos se utilizan para "Mecanismos de señalización" como "Ya he terminado, ahora puedo continuar"

Mutex solo puede liberarse por el hilo que lo adquirió, mientras que usted puede señalar el semáforo desde cualquier otro hilo (o proceso), por lo que los semáforos son más adecuados para algunos problemas de sincronización, como el productor-consumidor.

En Windows, los semáforos binarios son más como objetos de eventos que mutex.

Mutex trabaja en el bloqueo de la región crítica, pero el semáforo trabaja a la cuenta.

Mutex: Supongamos que tenemos un hilo de la sección crítica que T1 quiere acceder, luego sigue los pasos a continuación. T1:

Bloquear
Usar la sección crítica
desbloquear

Semáforo binario: funciona en base a la señalización de espera y señal. la espera (s) disminuye el valor de "s" en uno por lo general el valor de "s" se inicializa con el valor "1", la señal (es) aumenta el valor de "s" en uno. si el valor de "s" es 1 significa que nadie está usando la sección crítica, cuando el valor es 0 significa que la sección crítica está en uso. Supongamos que el hilo T2 está utilizando una sección crítica y luego sigue los pasos a continuación. T2:

espera (s) // inicialmente el valor de s es uno después de la espera de llamada su valor disminuyó en uno, es decir, 0
Usar la sección crítica
señal (es) // ahora el valor s aumenta y se convierte en 1

La principal diferencia entre Mutex y el semáforo binario está en Mutext si el subproceso bloquea la sección crítica, entonces tiene que desbloquear la sección crítica, ningún otro subproceso puede desbloquearlo, pero en el caso del semáforo binario si un subproceso bloquea la sección crítica utilizando la función de espera, entonces el valor s se convierte en "0" y nadie puede acceder a él hasta que el valor de "s" se convierta en 1, pero supongamos que alguna otra hebra llama a la (s) señal (es) y el valor de "s" se convierte a 1 y permite que otra función utilice la sección crítica. Por lo tanto, en el hilo del semáforo binario no tiene propiedad.

No son lo mismo. ¡Se utilizan para diferentes propósitos!
Si bien ambos tipos de semáforos tienen un estado lleno / vacío y usan la misma API, su uso es muy diferente.

Semáforos de exclusión mutua
Los semáforos de exclusión mutua se utilizan para proteger los recursos compartidos (estructura de datos, archivos, etc.).

Un semáforo Mutex es "propiedad" de la tarea que lo lleva. Si la Tarea B intenta obtener un mutex actualmente en poder de la Tarea A, la llamada de la Tarea B devolverá un error y fallará.

Los mutexes siempre usan la siguiente secuencia:

- SemTake - Critical Section - SemGive

Aquí hay un ejemplo simple:

Thread A Thread B Take Mutex access data ... Take Mutex <== Will block ... Give Mutex access data <== Unblocks ... Give Mutex

Semáforo binario
El semáforo binario aborda una pregunta totalmente diferente:

La tarea B está en espera de que ocurra algo (por ejemplo, un sensor que se dispara).
Viajes de sensores y una rutina de interrupción del servicio se ejecuta. Necesita notificar una tarea del viaje.
La tarea B debe ejecutarse y tomar las acciones apropiadas para el disparo del sensor. Entonces vuelve a esperar.

Task A Task B ... Take BinSemaphore <== wait for something Do Something Noteworthy Give BinSemaphore do something <== unblocks

Tenga en cuenta que con un semáforo binario, está bien que B tome el semáforo y que A lo dé.
Nuevamente, un semáforo binario NO protege un recurso de acceso. El acto de Dar y Tomar un semáforo está fundamentalmente desacoplado.
Por lo general, no tiene mucho sentido que la misma tarea sea dar y aceptar el mismo semáforo binario.

Obviamente, usa mutex para bloquear datos en un subproceso al que otro subproceso accede al mismo tiempo. Suponga que acaba de llamar a lock() y en el proceso de acceso a datos. Esto significa que no espera que ningún otro subproceso (u otra instancia del mismo código de subproceso) acceda a los mismos datos bloqueados por el mismo mutex. Es decir, si es el mismo código de subproceso que se ejecuta en una instancia de subproceso diferente, llega al bloqueo, entonces el lock() debe bloquear el flujo de control allí. Esto se aplica a un subproceso que utiliza un código de subproceso diferente, que también está accediendo a los mismos datos y que también está bloqueado por el mismo mutex. En este caso, todavía está en el proceso de acceder a los datos y puede tomar, digamos, otros 15 segundos para alcanzar el desbloqueo de exclusión mutua (de modo que el otro hilo que se está bloqueando en el bloqueo de exclusión mutua se desbloquearía y permitiría el control). acceder a los datos). ¿A cualquier costo, permite que otro hilo desbloquee el mismo mutex y, a su vez, permita que el hilo que ya está esperando (bloqueando) en el bloqueo de mutex desbloquee y acceda a los datos? Espero que tengas lo que estoy diciendo aquí? ¡Según la definición universal acordada!

con "mutex" esto no puede suceder. Ningún otro hilo puede desbloquear el bloqueo en tu hilo
con "semáforo binario" esto puede suceder. Cualquier otro hilo puede desbloquear el bloqueo de tu hilo.

Por lo tanto, si usted es muy particular en cuanto al uso de semáforos binarios en lugar de mutex, entonces debe tener mucho cuidado al "determinar" los bloqueos y desbloqueos. Me refiero a que cada flujo de control que llegue a cada bloqueo debería alcanzar una llamada de desbloqueo, además, no debería haber ningún "primer desbloqueo", sino que debería ser siempre "primer bloqueo".

Si bien se utilizan mutex y semáforos como primitivos de sincronización, existe una gran diferencia entre ellos. En el caso de mutex, solo el hilo que bloqueó o adquirió el mutex puede desbloquearlo. En el caso de un semáforo, un hilo que espera en un semáforo puede ser señalado por un hilo diferente. Algunos sistemas operativos admiten el uso de mutex y semáforos entre procesos. Normalmente el uso se crea en la memoria compartida.

Sus semánticas de sincronización son muy diferentes:

los mutexes permiten la serialización del acceso a un recurso dado, es decir, varios subprocesos esperan un bloqueo, uno por uno y, como se dijo anteriormente, el subproceso posee el bloqueo hasta que se realiza: solo este subproceso en particular puede desbloquearlo.
un semáforo binario es un contador con valor 0 y 1: una tarea que se bloquea en él hasta que cualquier tarea haga un sem_post. El semáforo anuncia que un recurso está disponible y proporciona el mecanismo para esperar hasta que se indique que está disponible.

Como tal, uno puede ver una exclusión mutua como un token pasado de tarea a tarea y un semáforo como luz roja de tráfico ( indica a alguien que puede continuar).

Un Mutex controla el acceso a un único recurso compartido. Proporciona operaciones para adquirir () acceso a ese recurso y liberarlo () cuando se realiza.

Un semáforo controla el acceso a un conjunto de recursos compartidos. Proporciona operaciones para Esperar () hasta que uno de los recursos en el grupo esté disponible, y Señale () cuando se devuelve al grupo.

Cuando la cantidad de recursos que protege un semáforo es mayor que 1, se llama semáforo de conteo . Cuando controla un recurso, se llama un semáforo booleano . Un semáforo booleano es equivalente a un mutex.

Así, un semáforo es una abstracción de nivel más alto que Mutex. Un Mutex puede implementarse utilizando un Semáforo pero no al revés.

El ejemplo del baño es una analogía agradable:

Mutex:
Es una llave para un inodoro. Una persona puede tener la llave, ocupar el baño, en ese momento. Cuando termina, la persona entrega (libera) la clave a la siguiente persona en la cola.
Oficialmente: "Mutexes se usa normalmente para serializar el acceso a una sección del código de reingreso que no puede ejecutarse simultáneamente por más de un hilo. Un objeto de mutex solo permite un hilo en una sección controlada, forzando otros hilos que intentan acceder a esa sección esperará hasta que el primer hilo haya salido de esa sección ". Ref: Symbian Developer Library
(Un mutex es realmente un semáforo con valor 1).
Semáforo:
Es el número de llaves de baño idénticas gratis. Ejemplo, digamos que tenemos cuatro baños con cerraduras y llaves idénticas. El recuento de semáforos, el recuento de claves, se establece en 4 al principio (los cuatro inodoros son gratuitos), luego el valor del recuento disminuye a medida que entran personas. Si todos los inodoros están llenos, es decir. no quedan claves libres, el recuento de semáforos es 0. Ahora, cuando eq. una persona sale del inodoro, el semáforo se incrementa a 1 (una llave gratis) y se entrega a la siguiente persona en la cola.
Oficialmente: "Un semáforo restringe el número de usuarios simultáneos de un recurso compartido hasta un número máximo. Los subprocesos pueden solicitar acceso al recurso (disminuyendo el semáforo) y pueden indicar que han terminado de usar el recurso (aumentar el semáforo). " Ref: Symbian Developer Library

http://www.geeksforgeeks.org/archives/9102 discute en detalles.

Mutex es el mecanismo de bloqueo utilizado para sincronizar el acceso a un recurso. Semaphore es un mecanismo de señalización.

Depende de programador si quiere usar un semáforo binario en lugar de mutex.

Casi todo lo anterior lo dijo bien. Permítame también intentar mi parte para aclarar si alguien todavía tiene una duda. Mutex -> utilizado para la serialización Semaphore-> sincronización. El propósito de ambos es diferente, sin embargo, la misma funcionalidad podría lograrse a través de ambos con una programación cuidadosa. Ejemplo estándar-> problema del consumidor productor. valor inicial de SemaVar = 0

Productor Consumidor --- SemaWait () -> decrementa SemaVar

producir datos

SemaSignal SemaVar o SemaVar ++ ---> consumidor desbloquea como SemVar es 1 ahora.

Espero poder aclarar.

Como mucha gente mencionó aquí, se usa un mutex para proteger una pieza crítica de código (también conocida como sección crítica). Adquirirá el mutex (bloqueo), ingresará a la sección crítica y liberará el mutex (desbloqueo) en el mismo hilo .

Mientras usa un semáforo, puede hacer que un hilo espere en un semáforo (por ejemplo, hilo A), hasta que otro hilo (por ejemplo, hilo B) complete cualquier tarea y luego establezca el Semáforo para que el hilo A detenga la espera y continúe con su tarea.

El semáforo mutex y binario tiene el mismo uso pero, en realidad, son diferentes. En caso de exclusión mutua, el hilo que lo ha bloqueado, solo eso puede desbloquearlo. Si cualquier otro hilo viene a bloquearlo, esperará. Pero en el caso del semáfono, no es el caso. El semáforo no está vinculado con un ID de hilo partucular.

Los mutexes tienen propiedad, a diferencia de los semáforos. Aunque cualquier hilo, dentro del alcance de un mutex, puede obtener un mutex desbloqueado y bloquear el acceso a la misma sección crítica del código, solo el hilo que bloqueó un mutex debería desbloquearlo .

Un Mutex , por definición, se usa para serializar el acceso a una sección del código de reingreso que no puede ejecutarse simultáneamente por más de un hilo.
Un semáforo , por definición, restringe el número de usuarios simultáneos de un recurso compartido hasta un número máximo
Un semáforo puede ser un Mutex, pero un Mutex nunca puede ser un semáforo. Esto simplemente significa que se puede usar un semáforo binario
como Mutex, pero un Mutex nunca puede exhibir la funcionalidad del semáforo.
Tanto los semáforos como Mutex (al menos el último núcleo) son de naturaleza no recursiva.
Nadie es dueño de semáforos, mientras que Mutex es de su propiedad y el propietario es responsable de ellos. Esta es una distinción importante desde una perspectiva de depuración.
En el caso de Mutex, el hilo que posee el Mutex es responsable de liberarlo. Sin embargo, en el caso de los semáforos, esta condición no es necesaria. Cualquier otro hilo puede señalar para liberar el semáforo usando smps (function.e_ot)
Otra diferencia que le importaría a los desarrolladores es que los semáforos abarcan todo el sistema y permanecen en forma de archivos en el sistema de archivos, a menos que se limpien de otro modo. Los procesos mutex se realizan en todo el proceso y se limpian automáticamente cuando sale un proceso.
La naturaleza de los semáforos hace posible usarlos en la sincronización de procesos relacionados y no relacionados, así como entre subprocesos. Mutex solo se puede utilizar para sincronizar subprocesos y, a lo sumo, entre procesos relacionados (la implementación pthread del último kernel viene con una característica que permite utilizar Mutex entre procesos relacionados).
De acuerdo con la documentación del núcleo, los Mutex son más ligeros en comparación con los semáforos. Lo que esto significa es que un programa con uso de semáforo tiene una mayor huella de memoria en comparación con un programa que tiene Mutex.
Desde una perspectiva de uso, Mutex tiene una semántica más simple en comparación con los semáforos.