Что происходит с Mutex, когда поток, который его приобрел, выходит?

Предположим, что есть два потока, основной поток и поток B (созданный главным образом). Если B получил мьютекс (скажем pthread_mutex), и он вызвал pthread_exit без разблокировки блокировки. Итак, что происходит с мьютексом? Он становится свободным?

Ответы

Ответ 1

Нету. Мьютекс остается заблокированным. То, что на самом деле происходит с таким замком, зависит от его типа, вы можете прочитать об этом здесь или здесь

Ответ 2

Если вы создали надежный мьютекс, настроив нужные атрибуты перед вызовом pthread_mutex_init, мьютекс войдет в специальное состояние, когда поток, который удерживает блокировку, завершается, а следующий поток, чтобы попытаться получить мьютекс, получит ошибка EOWNERDEAD. Затем он отвечает за очистку любого состояния, которое защищает мьютекс, и вызов pthread_mutex_consistent для повторного использования мьютекса или вызова pthread_mutex_unlock (что сделает мьютекс навсегда непригодным для использования, а дальнейшие попытки использовать его вернут ENOTRECOVERABLE).

Для ненадежных мьютексов мьютекс постоянно непригоден, если поток, который заблокировал его, завершает работу без его разблокировки. По стандарту (см. Разрешение вопрос 755 на трекер Austin Group), мьютекс остается заблокированным, и его формальное владение продолжает принадлежать потоку который вышел, и любой поток, который пытается заблокировать его, закроется. Если другой поток пытается разблокировать его, это обычно поведение undefined, если мьютекс не был создан с атрибутом PTHREAD_MUTEX_ERRORCHECK, и в этом случае будет возвращена ошибка.

С другой стороны, многие (большинство?) реализаций реального мира фактически не соответствуют требованиям стандарта. Попытка заблокировать или разблокировать мьютекс из другого потока может оказаться неудачно, поскольку идентификатор потока (используемый для отслеживания права собственности) может быть повторно использован и теперь может ссылаться на другой поток (возможно, тот, который делает новый запрос блокировки/разблокировки). Известно, что, как минимум, glibc NPTL проявляет такое поведение.