Семафоры и завершение процесса.

Кажется, в структуре sembuf есть поле флагов sem_flg, в которое можно добавить флаг SEM_UNDO. Если флаг установлен, то ядро будет следить за изменениями значения семафора. Если процесс, изменивший значение семафора, рухнет (или «забудет» сделать обратное изменение при выходе из крит.секции), то ядро скорректирует значение семафора, чтобы не было вечной блокировки ждущих процессов. Как-то так. /* давно не писал с семафорами, могу где-то ошибаться */

Например, обрабатывать сигналы SIGSEG и прочее.

Хм интересно. Но это немного другие семафоры. Ну да ладно, это не принипиально.

Думаю, минут 10 тебе хватит, чтобы написать нужную программу, запустить и в момент sleep() сделать ей kill -9 (так, чтобы она нечего не поняла).

Затем снова запустить, чтобы проверить состояние семафора. Еще есть команды ipcs, ipcrm, ipcmk, они тоже про какие-то семафоры.

Я могу ошибаться, но мне кажется, ты хочешь странного. Если у тебя упал один из рабочих потоков, значит у тебя возникла аварийная ситуация и ее надо обрабатывать, а не продолжать работу, как ни в чем не бывало. Тут уж не до блокировок, хотя и их можно разрулить в обработке исключений.

Ога, вотчдог перезапустит умерший процесс и матернется в лог. А как еще обрабатывать? Особенно если это случилось 1го января час ночи.

аварийная ситуация и ее надо обрабатывать, а не продолжать работу

Не всегда. Для задач «требующих повышенной надежности», сразу же оговариваются: в программах всегда есть баги, программы всегда «падают» и т.п. Если принять это как истину, то один из методов борьбы с этим это подготовиться к некорректному поведению, и создавать программы так, что они могут продолжать работать даже если что-то где-то сломалось.

Для этого придумывался robust mutexes (ядро разлочит mutex взятый потоком, если поток случайно умрет). Почти такой же функционал предоставляет SEM_UNDO для семафоров, с тем отличием, что robust mutex'ы могут сообщать, что мьютекс разлочился в силу смерти потока (EOWNERDEAD + pthread_mutex_consistent), и тред среагирует соответствующим образом. У семафоров такой механизм оповещения об ошибке нужно самому придумывать.

Если же хватает просто mutex'a, то можно заменить семфор на pthread mutex + pthread_mutexattr_setpshared + pthread_mutexattr_setrobust.

Вы меня не поняли. Баги, конечно же, есть всегда, но это не значит, что падение потоков нужно игнорировать. У вас потоки просто так крутятся или обрабатывают какие-то свои уникальные наборы данных? Вы же не хотите эти данные потерять вместе с потоком? Что мешает отлавливать падения и по возможности проводить диагностику, а в конце перезапускать поток с этими же данными?

Если же хватает просто mutex'a, то можно заменить семфор на pthread mutex + pthread_mutexattr_setpshared + pthread_mutexattr_setrobust.

Это типо глобальный мьютекс? А оно везде работает? У меня просто эмбедед и не понятно чо там есть, чего нет.

что падение потоков нужно игнорировать

Ну и никто не говорит про игнорирование. Вы же сами говорите:

Что мешает отлавливать падения и по возможности проводить диагностику

Так без SEM_UNDO/robust mutexes вы просто не сможете ничего отлавливать, так как у вас будет deadlock. Кто разблокирует mutex/semaphore?

А со средствами экстренной разблокировки вы отловите ситуацию, поймете, что поток/процесс умер, проведете «диагностику», и попробуете заново (или залогируете, что вот такая-то часть данных вызывает падение, и пойдете дальше обрабатывать, другие данные).

кретической

кретическое программирование - это такая эзотерическая практика экстремального :)

Это типо глобальный мьютекс?

Да, в shared memory можно создать.

А оно везде работает?

Если соответствует POSIX.1c. Но всегда смотреть нужно по обстоятельствам. Linux, например, на 100% не соответствует стандартам, и не будет (нету такой цели у разработчиков), но именно эта фича в glibc/Linux работать должна.

У меня просто эмбедед и не понятно чо там есть, чего нет.

Смотря какой embedded. bionic, uclibc? В любом случае, проще просто скомпилировать пример и посмотреть.