sem_wait и обработчик сигнала

Question

Почему sem_wait нельзя использовать внутри обработчика сигнала (в частности, сигнала SIGSEGV для каждого потока)?Может кто-нибудь привести пример сценария, в котором будет зависать приложение?Я думаю, sem_wait является реентерабельным и поточно-безопасным , так в чем здесь проблема?Почему это не асинхронно безопасно ?

Answer 1

Асинхронная безопасность - намного более строгое требование, чем безопасность потоков.Вы можете написать потокобезопасный код, используя примитивы для защиты глобальных данных с критическими секциями.Обработчики сигналов не могут полагаться на это.Например, вы можете находиться внутри критической секции в sem_wait и одновременно делать что-то, что вызывает segfault.Это сломало бы потокобезопасную защиту sem_wait.

Answer 2

sem_wait нельзя использовать в обработчике сигналов по этой причине:

Поток A вызывает sem_wait для sem1.Когда поток A закончен, он отправляет сообщение в sem1.Однако, прежде чем он может закончить, сигнал получен, и затем вводится обработчик, вызывающий sem_wait для sem1.Поскольку A - это то, что будет отправлять в sem1, обработчик никогда не вернется, и у вас будет тупик.Вот почему это хорошее правило - никогда не ждать чего-либо в обработчике сигналов.Проблема, ASFAIK, больше связана с взаимоблокировкой, чем сбоем.

Кроме того, это нарушает идеальную цель обработчика сигнала - обработать внешнее прерывание и затем быстро вернуться к тому, что вы делали.

Наконец, не лучше ли избавиться от SIGSEGV вместо того, чтобы обращаться с ним?

Answer 3

Что если приложение получает сигнал, когда значение семафора равно нулю, а поток, который получает сигнал, оказывается тем, который должен увеличивать значение семафора (sem_post)? Если вы затем вызовете sem_wait в обработчике сигналов, процесс будет заблокирован, нет?

Другим аргументом может быть, конечно, то, что если sem_wait отсутствует в списке функций, безопасных для асинхронных сигналов, реализация может вызывать назальных демонов.