Что произойдет, если вы подадите сигнал (сигнал ОС, а не pthread_mutex_unlock) о процессе, заблокированном в pthread_mutex_wait

Question

Меня сбивает с толку то, что pthread_mutex_lock не имеет E_INTR в качестве возвращаемого значения. Хотя pthread_cond_wait может быть ложно пробужден и возвращать 0, из-за того, что l oop и Mesa контролируют семантику, это не проблема.

Итак, если процесс заблокирован pthread_mutex_lock, и вы отправляете сигнал, чтобы разбудить его, после выполнения обработчика сигнала, что произойдет? Есть ли механизм, чтобы избежать этого ложного пробуждения?

Answer 1

если процесс заблокирован pthread_mutex_lock, и вы отправляете сигнал для его активации после выполнения обработчика сигнала, что произойдет?

Если обработчик сигнала этого не сделал Вызовите любые небезопасные асинхронные c -сигнальные операции, затем после того, как обработчик вернется, процесс продолжит ожидать мьютекса.

Если обработчик сигнала вызвал небезопасную асинхронную c -сигнальную операцию (например, разблокирован мьютекс), поведение не определено: может произойти все, что угодно , включая (но не ограничиваясь) сбой, блокировку навсегда, появление работы "нормально" и т. д. c. и др c.