Diferencia entre semáforo binario y mutex

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

NO son lo mismo. Se usan para diferentes propósitos!
Si bien ambos tipos de semáforos tienen un estado completo / 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 semivar un mutex actualmente retenido por la Tarea A, la llamada de la Tarea B devolverá un error y fallará.

Los mutexes siempre usan la siguiente secuencia:

   - SemTake
   - Sección crítica
   - SemGive 

Aquí hay un ejemplo simple:

   Hilo A Hilo B
    Tome Mutex
      datos de acceso
      ... Tome Mutex < == Will bloqueará
      ...
    Dar datos de acceso de Mutex <== Desbloquea
                                   ...
                                 Dar Mutex

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

  • La tarea B está pendiente esperando que ocurra algo (un sensor que se dispara, por ejemplo).
  • Se ejecuta Exámenes de sensor y una rutina de servicio de interrupción. Necesita notificar una tarea del viaje.
  • La tarea B debe ejecutarse y tomar las medidas apropiadas para el viaje del sensor. Luego 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 A para darlo.
De nuevo, un semáforo binario NO protege un recurso del acceso. El acto de dar y tomar un semáforo está fundamentalmente desacoplado.
Por lo general, tiene poco sentido para la misma tarea dar y tomar el mismo semáforo binario.

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

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

El ejemplo de Toilet es una analogía agradable:

Mutex:

Es la llave de un baño. Una persona puede tener la llave, ocupar el baño, en ese momento. Cuando termina, la persona da (libera) la llave a la siguiente persona en la cola.

Oficialmente: “Los mensajes mutex se utilizan generalmente para serializar el acceso a una sección de código de reentrada que no se puede ejecutar simultáneamente por más de un hilo. Un objeto mutex solo permite un hilo en una sección controlada, forzando a otros hilos que intentan obtener acceso a esa sección para 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 la cantidad de llaves de inodoro idénticas gratuitas. 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 retretes son gratuitos), luego el valor del recuento disminuye a medida que las personas ingresan. Si todos los retretes están llenos, es decir, no quedan claves libres, el recuento de semáforos es 0. Ahora, cuando eq. una persona deja el baño, el semáforo aumenta a 1 (una tecla libre) y se le da a la siguiente persona en la fila.

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 (decrementando el semáforo) y pueden indicar que han terminado de usar el recurso (incrementando el semáforo). ” Ref: Symbian Developer Library

Buenos artículos sobre el tema:

  • MUTEX VS. SEMAPHORES – PARTE 1: SEMAPHORES
  • MUTEX VS. SEMAPHORES – PARTE 2: EL MUTEX
  • MUTEX VS. SEMAPHORES – PARTE 3 (PARTE FINAL): PROBLEMAS DE EXCLUSIÓN MUTUA

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) un mutex solo, puede desbloquearlo. Si una tarea intenta desbloquear un mutex que no se ha bloqueado (por lo tanto, no posee), entonces se encuentra una condición de error y, lo más importante, el mutex no está desbloqueado. Si el objeto de exclusión mutua no tiene propiedad, entonces, es irrelevante de lo que se llama, no es un mutex.

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

Estrictamente hablando, un mutex es un mecanismo de locking utilizado para sincronizar el acceso a un recurso. Solo una tarea (puede ser un subproceso o un proceso basado en la abstracción del SO) puede adquirir el mutex. Significa que habrá propiedad asociada con mutex, y solo el propietario puede liberar el locking (mutex).

Semaphore es un mecanismo de señalización (tipo de señal “He terminado, puedes continuar”). Por ejemplo, si está escuchando canciones (asúmelas como una tarea) en su teléfono móvil y al mismo tiempo su amigo lo llamó, se activará una interrupción en la que una rutina de servicio de interrupción (ISR) señalará la tarea de procesamiento de llamadas para despertar .

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

Su semántica de sincronización es muy diferente:

  • Los mutexes permiten la serialización del acceso a un recurso dado, es decir, múltiples hilos esperan un locking, uno a la vez y como se dijo anteriormente, el hilo posee el locking hasta que se completa: solo este hilo en particular puede desbloquearlo.
  • un semáforo binario es un contador con valor 0 y 1: una tarea que lo bloquea hasta que cualquier tarea haga un sem_post. El semáforo anuncia que hay un recurso disponible y proporciona el mecanismo para esperar hasta que se indique que está disponible.

Como tal, uno puede ver un mutex como un token pasado de tarea a tareas y un semáforo como semáforo en rojo (le indica a alguien que puede continuar).

En un nivel teórico, no son diferentes semánticamente. Puedes implementar un mutex usando semáforos o viceversa (mira aquí 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 está destinada a ser un mecanismo de sincronización más ligero. En el habla del oracle, los mutexes se conocen como pestillos y los semáforos se conocen como esperas .

En el nivel más bajo, usan algún tipo de prueba atómica y establecen un mecanismo. Esto lee el valor actual de una ubicación de memoria, calcula algún tipo de condición 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 una prueba para ver si alguien más lo tenía antes que usted.

Una implementación típica de mutex tiene un proceso o subproceso que ejecuta la instrucción de prueba y configuración y evalúa si algo más ha establecido el mutex. Un punto clave aquí es que no hay interacción con el progtwigdor , por lo que no tenemos idea (y no me importa) quién ha establecido el locking. A continuación, cedemos nuestra porción de tiempo e intentamos nuevamente cuando la tarea se vuelve a progtwigr o ejecutamos un locking de giro . Un locking 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 sección crítica ) simplemente estableceremos el valor mutex en cero o lo que sea que signifique ‘claro’. Si varias tareas intentan adquirir el mutex, la próxima tarea que se programe después de liberar el mutex tendrá acceso al recurso. Por lo general, debe usar mutexes para controlar un recurso sincronizado donde el acceso exclusivo solo es necesario por periodos de tiempo muy cortos, normalmente para realizar una actualización de una estructura de datos compartida.

Un semáforo es una estructura de datos sincronizados (generalmente con un mutex) que tiene un recuento y algunas envolturas de llamadas al sistema que interactúan con el planificador con un poco más de profundidad que las bibliotecas mutex. Los semáforos se incrementan y decrementan y se usan para bloquear tareas hasta que algo más esté listo. Vea Producer / Consumer Problem 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 activar 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 reducirán la velocidad de una sola máquina procesadora. Solo usaría un spinlock en una caja multiprocesador porque en un solo procesador el proceso que contiene el mutex nunca lo reiniciará mientras se está ejecutando otra tarea. Los spinlocks solo son útiles en architectures multiprocesador.

Aunque mutex y semáforos se utilizan como primitivas 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.

  • Un Mutex , por definición, se utiliza para serializar el acceso a una sección de código de reentrantes que no se puede ejecutar simultáneamente por más de un hilo.

  • Un semáforo , por definición, restringe la cantidad 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.

  • Ambos semáforos y Mutex (al menos el último kernel) son de naturaleza no recursiva.
  • Nadie posee semáforos, mientras que Mutex es 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 indicar que se libere el semáforo utilizando los smps (function.e_ot)

  • Otra diferencia que importaría a los desarrolladores es que los semáforos son de todo el sistema y permanecen en forma de archivos en el sistema de archivos, a menos que se limpien de otra manera. Los mutex se procesan en todo el proceso y se limpian automáticamente cuando finaliza un proceso.

  • La naturaleza de los semáforos hace posible utilizarlos en la sincronización de procesos relacionados y no relacionados, así como también entre hilos. Mutex solo se puede usar para sincronizar hilos y, como máximo, entre procesos relacionados (la implementación pthread del último núcleo viene con una característica que permite usar Mutex entre procesos relacionados).
  • De acuerdo con la documentación del kernel, los Mutex son más ligeros en comparación con los semáforos. Lo que esto significa es que un progtwig con uso de semáforo tiene una huella de memoria mayor en comparación con un progtwig que tiene Mutex.
  • Desde una perspectiva de uso, Mutex tiene una semántica más simple en comparación con los semáforos.

Obviamente, utiliza mutex para bloquear los datos en un subproceso al que se accede por otro subproceso al mismo tiempo. Supongamos que acaba de llamar a lock() y está en proceso de acceder a los datos. Esto significa que no espera que ningún otro hilo (u otra instancia del mismo código de hilo) acceda a los mismos datos bloqueados por el mismo mutex. Es decir, si se ejecuta el mismo código de subproceso en una instancia de subproceso diferente, se activa el locking, entonces el lock() debería bloquear el flujo de control allí. Esto se aplica a un hilo que usa un código de hilo diferente, que también está accediendo a los mismos datos y que también está bloqueado por el mismo mutex. En este caso, aún está en el proceso de acceder a los datos y puede tomar, por ejemplo, otros 15 segundos para alcanzar el deslocking de mutex (para que el otro hilo que se bloquee en el locking de exclusión mutua se desbloquee y permita el control acceder a los datos). ¿Permitirá, a cualquier precio, otro hilo para desbloquear el mismo mutex y, a su vez, permitir que el hilo que ya está esperando (locking) en el locking de exclusión mutua desbloquee y acceda a los datos? Espero que tengas lo que estoy diciendo aquí? Según, ¡de acuerdo con la definición universal!

  • con “mutex” esto no puede suceder. Ningún otro hilo puede desbloquear el locking en su hilo
  • con “semáforo binario” esto puede suceder. Cualquier otro hilo puede desbloquear el locking en tu hilo

Por lo tanto, si usted es muy particular sobre el uso de semáforos binarios en lugar de mutex, entonces debe tener mucho cuidado al “trazar” los lockings y deslockings. Quiero decir que cada control de flujo que golpea cada locking debe golpear una llamada de deslocking, también no debe haber ningún “primer deslocking”, sino que debe ser siempre “primer locking”.

Mutex se utilizan para “Mecanismos de locking”. un proceso a la vez puede usar un recurso compartido

mientras

Los semáforos se usan para “Mecanismos de señalización” como “Ya terminé, ahora puedo continuar”

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

  1. Un mutex solo puede ser liberado por el hilo que tiene la propiedad, es decir, el hilo que anteriormente llamaba la función Wait, (o que tomó posesión al crearlo). Un semáforo puede ser lanzado por cualquier hilo.

  2. Un hilo puede llamar a una función de espera repetidamente en un mutex sin locking. Sin embargo, si llama a una función de espera dos veces en un semáforo binario sin soltar el semáforo en medio, el hilo se bloqueará.

Mito:

Un par de artículos dice que “semáforo binario y mutex son iguales” o “semáforo con valor 1 es mutex”, pero la diferencia básica es que Mutex solo puede lanzarse por hilo que lo haya adquirido, mientras que usted puede señalar semáforos desde cualquier otro hilo

Puntos clave:

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

• Un mutex se puede bloquear más de una vez solo si es un mutex recursivo, aquí el locking y deslocking para mutex debería ser el mismo

• Si un hilo que ya había bloqueado un mutex, intenta bloquear el mutex de nuevo, entrará en la lista de espera de ese mutex, lo que resulta en un punto muerto.

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

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

• El objective principal de mutex es lograr el acceso atómico o bloquear el recurso

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

Un semáforo controla el acceso a un grupo compartido de recursos. Proporciona operaciones a Wait () hasta que uno de los recursos del grupo esté disponible, y Signal () cuando se devuelve al grupo.

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

Por lo tanto, un semáforo es una abstracción de mayor nivel que Mutex. Un Mutex puede implementarse utilizando un semáforo pero no al revés.

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

  1. Bloquear
  2. Utilice la sección crítica
  3. desbloquear

Semáforo binario: funciona según la señalización de espera y señal. espere (s) disminuya el valor de “s” en uno, por lo general, el valor de “s” se inicializa con el valor “1”, la (s) señal (es) aumenta (n) el valor de “s” en uno. si el valor “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, entonces sigue los pasos a continuación. T2:

  1. espera (s) // inicialmente el valor s es uno después de la llamada espere su valor disminuido en uno, es decir, 0
  2. Use la sección crítica
  3. señal (es) // ahora el valor s se incrementa y se convierte en 1

La diferencia principal entre Mutex y el semáforo binario está en Mutext si el hilo bloquea la sección crítica y luego tiene que desbloquear la sección crítica, ningún otro hilo puede desbloquearla, pero en el caso del semáforo binario si un hilo bloquea la sección crítica usando la función wait (s) de s se convierten en “0” y nadie puede acceder hasta que el valor de “s” se convierta en 1, pero supongamos que alguna otra cadena llama a la (s) señal (es) y el valor de “s” se convierte en 1 y permite que otra función use sección crítica. por lo tanto, en el hilo del semáforo binario no tiene propiedad.

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

Respuestas: Las siguientes son las diferencias: i) Ámbito: el scope de mutex está 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 todo 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 incluso más rápido.

iii) Mutex puede ser adquirido por el mismo hilo exitosamente varias veces con la condición de que debería liberarlo el mismo número de veces. Otro hilo tratando de adquirir se bloqueará. Mientras que en el caso del semáforo si el mismo proceso intenta volver a adquirirlo, bloquea ya que solo se puede adquirir una vez.

Mutex trabaja en el locking de la región crítica, pero el trabajo de Semáforo en el recuento.

http://www.geeksforgeeks.org/archives/9102 analiza en detalle.

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

Es hasta progtwigdor si quiere usar semáforo binario en lugar de mutex.

Diferencia entre semáforo binario y mutex: PROPIEDAD: los semáforos se pueden señalar (publicar) incluso desde un propietario no actual. Significa que simplemente puede publicar desde cualquier otro hilo, aunque usted no es el propietario.

Semaphore es una propiedad pública en proceso. Puede publicarse simplemente mediante un hilo que no sea propietario. Marque esta diferencia en letras en negrita, significa mucho.

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

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

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

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

 #include  #include  #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; } 

Las diferencias entre semáforo binario y mutex son:

Mutex se usa exclusivamente para la exclusión mutua. Tanto la exclusión mutua como la sincronización pueden usarse por binario. Una tarea que tomó mutex solo puede dar mutex. Desde un ISR, no se puede dar un mutex. La toma recursiva de semáforos de exclusión mutua es posible. Esto significa que una tarea que se mantiene antes de liberar finalmente un semáforo, puede tomar el semáforo más de una vez. Las opciones para realizar la tarea que toma como DELETE_SAFE las proporciona Mutex, lo que significa que la eliminación de tareas no es posible cuando se mantiene el mutex.

Si bien un semáforo binario se puede usar como un mutex, un mutex es un caso de uso más específico, ya que solo se supone que el proceso que bloqueó el mutex debe desbloquearlo. Esta restricción de propiedad permite brindar protección contra:

  • Lanzamiento accidental
  • Punto muerto recursivo
  • Punto muerto de la 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 de comprobación de errores en su mutex. Si se EDEADLK error de EDEADLK devuelve EDEADLK si intentas bloquear el mismo dos veces y EPERM si desbloqueas un mutex que no es tuyo.

 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 inicializado, podemos colocar estos controles en nuestro código de esta manera:

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

Mutex se utiliza para proteger el código y los datos confidenciales, el semáforo se utiliza para la sincronización. También puede tener un uso práctico para proteger el código sensible, pero podría existir el riesgo de liberar la protección mediante el otro hilo mediante la operación V.So. la diferencia entre bi-semáforo y mutex es la propiedad. Por ejemplo, por el inodoro, Mutex es como que uno puede entrar al baño y cerrar la puerta, nadie más puede entrar hasta que el hombre salga, bi-semáforo es como que uno puede ingresar el inodoro y cierra con llave la puerta, pero alguien más podría entrar pidiéndole al administrador que abra la puerta, es ridículo.

La respuesta puede depender del sistema operativo objective. Por ejemplo, al menos una implementación de RTOS con la que estoy familiarizado permitirá múltiples operaciones secuenciales de “obtención” contra un solo mutex del sistema operativo, siempre que todos sean del mismo contexto de subproceso. Los múltiples get deben ser reemplazados por un número igual de puts antes de que otro thread pueda obtener el mutex. Esto difiere de los semáforos binarios, para los que solo se permite un único acceso a la vez, independientemente de los contextos de subprocesos.

The idea behind this type of mutex is that you protect an object by only allowing a single context to modify the data at a time. Even if the thread gets the mutex and then calls a function that further modifies the object (and gets/puts the protector mutex around its own operations), the operations should still be safe because they’re all happening under a single thread.

 { 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. } 

Of course, when using this feature, you must be certain that all accesses within a single thread really are safe!

I’m not sure how common this approach is, or whether it applies outside of the systems with which I’m familiar. For an example of this kind of mutex, see the ThreadX RTOS.

Mutexes have ownership, unlike semaphores. Although any thread, within the scope of a mutex, can get an unlocked mutex and lock access to the same critical section of code, only the thread that locked a mutex should unlock it .

Mutex & Binary semaphore is both of same usage but in reality, They are different. In Case of mutex, The Thread which have Locked it, Only that can unlock it. If any other thread comes to lock it, It will wait. But in Case of semaphone, Its not the case. Semaphore is not tied up with a partucular thread ID.

As many folks here have mentioned, a mutex is used to protect a critical piece of code (AKA critical section.) You will acquire the mutex (lock), enter critical section, and release mutex (unlock) all in the same thread .

While using a semaphore, you can make a thread wait on a semaphore (say thread A), until another thread (say thread B)completes whatever task, and then sets the Semaphore for thread A to stop the wait, and continue its task.

Almost all of the above said it right. Let me also try my bit to clarify if somebody still has a doubt. Mutex -> used for serialization Semaphore-> synchronization. Purpose of both are different however, same functionality could be achieved through both of them with careful programming. Standard Example-> producer consumer problem. initial value of SemaVar=0

Producer Consumer — SemaWait()->decrement SemaVar

produce data

SemaSignal SemaVar or SemaVar++ —>consumer unblocks as SemVar is 1 now.

Hope I could clarify.