pthread_mutex_lock - ¿Qué le sucede a Mutex cuando sale el hilo que lo adquirió?

pthread_mutex_init

Question

Supongamos que hay dos hilos, el hilo principal y el hilo B (creados por main). Si B adquirió un mutex (digamos pthread_mutex) y ha llamado a pthread_exit sin desbloquear el bloqueo. Entonces, ¿qué pasa con el mutex? ¿Se vuelve libre?

Answer 1

nop El mutex queda bloqueado. Lo que realmente le sucede a dicho bloqueo depende de su tipo. Puede leerlo here o here

Answer 2

Si creó un mutex sólido al configurar los atributos correctos antes de llamar a pthread_mutex_init , el mutex entrará en un estado especial cuando finalice el hilo que contiene el bloqueo, y el siguiente hilo que intente adquirir el mutex obtendrá un error de EOWNERDEAD . Entonces, es responsable de limpiar el estado que protege mutex y llamar a pthread_mutex_consistent para hacer que el mutex sea utilizable nuevamente, o llamar a pthread_mutex_unlock (lo que hará que el mutex sea inutilizable; los intentos adicionales de usarlo devolverán ENOTRECOVERABLE ).

Para mutexes no robustos, el mutex es permanentemente inutilizable si el hilo que lo bloqueó termina sin desbloquearlo. Según la norma (consulte la resolución para emitir 755 en el rastreador de Austin Group), la exclusión mutua permanece bloqueada y su propiedad formal continúa perteneciendo al subproceso que salió, y cualquier subproceso que intente bloquearlo se bloqueará. Si otro subproceso intenta desbloquearlo, normalmente se trata de un comportamiento indefinido, a menos que el mutex se haya creado con el atributo PTHREAD_MUTEX_ERRORCHECK , en cuyo caso se devolverá un error.

Por otro lado, muchas (¿la mayoría?) Implementaciones del mundo real en realidad no cumplen con los requisitos de la norma. Un intento de bloquear o desbloquear la exclusión mutua de otro subproceso podría tener éxito falsamente, ya que la identificación del subproceso (utilizada para rastrear la propiedad) podría haberse reutilizado y ahora podría referirse a un subproceso diferente (posiblemente el que realiza la nueva solicitud de bloqueo / desbloqueo). Se sabe que al menos el NPTL de glibc exhibe este comportamiento.