Семафоры и дохнущий процесс

shared memory

Нафига? Чем unix сокеты не устроили?

Альтернатива - flock на файл. Не подходит отсутствием таймаута (клиенту важно).

alarm + EINTR

Сделай две очереди (ring), в одну очередь сервер кладёт номера буферов, которые можно обрабатывать, в другую - клиент уже обработанных буферов, из которой сервер потом может их брать и переиспользовать. Ищи lockless ringbuffer, их полно. Можно из DPDK выдрать, чтобы всё не тащить.

Нафига? Чем unix сокеты не устроили?

Один фрейм весит 8мб. Фреймов может быть в районе 30 в секунду.

alarm + EINTR

Как костыль сойдет, но хотелось бы чего-то менее уродского.

https://man7.org/linux/man-pages/man3/pthread_mutexattr_setrobust.3.html

Но да, IPC для многопотоков и разделяемой памяти в POSIX отвратительное из-за форка, так что готовься к трудностям. Так всегда получается, когда спеки пишут комитеты, а не программисты.

Норм решение. Оставлю на случай, если чего-то менее простого не найдется.

Один фрейм весит 8мб. Фреймов может быть в районе 30 в секунду.

Передавай ссылку на буфер в shm через сокет. Короче, передача сообщений вместо блокировок.

У меня культурный шок просто из-за того, что семафоры сделаны через жопу. Очевидная же необходимость в SEM_UNDO, какого хрена этого нет в посиксе?

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

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

У меня культурный шок просто из-за того, что семафоры сделаны через жопу. Очевидная же необходимость в SEM_UNDO, какого хрена этого нет в посиксе?

Это POSIX,1-2008:

https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/idx/ip.html

Шаренная память это не для всех. Это очень низкоуровневая штука. Плюсую кольцевые буфера или юникс-сокеты

Обработка ошибок написана хорошо. Просто мир несовершенен и произойти может все что угодно. Поэтому всякого рода обработчики сигналов для освобождения семафоров идут лесом. Прилетит SIGKILL - и труба.

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

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

Вот именно поэтому я и хочу это использовать, чтобы целевая платформа (арм) не загнулась от межпроцессного жонглирования данными.

Шаренная память это не для всех. Это очень низкоуровневая штука. Плюсую кольцевые буфера или юникс-сокеты

Разделяемая память не более низкоуровнева, чем сокеты. Проблема не в низкоуровневости, а в недоработанности посиксового IPC.

2all: всем спасибо за советы. Решение с кольцевыми буферами и сокетами для контроля выглядит нормальным, но слишком громоздким как по мне. Если других вариантов не найдется, то буду делать что-нибудь из этого. Может быть существует какой-нибудь уродский linux-only хак? С фьютексами там, хз.

Cast i-rinat

Тут нет моей или твоей логики, есть логика высвобождать ресурсы перед смертью, неважно от каких причин эта смерть наступает. А если ты не можешь этого сделать корректно, о чём вообще тогда может идти речь?

Осуждаю такой подход, но если тебе нормально, дело твое.

Ты в принципе не можешь корректно «освободить» взятый семафор, потому что циферка в семафоре по какому-то идиотизму не считается ресурсом.

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

логика высвобождать ресурсы перед смертью, неважно от каких причин эта смерть наступает. А если ты не можешь этого сделать корректно, о чём вообще тогда может идти речь?

Ты предлагаешь писать свою ОС, которая высвободит свои ресурсы?

flock на файл. Не подходит отсутствием таймаута

У flock() есть флаг LOCK_NB, который делает его неблокирующим.

несколько сырых fhd@50 uyvy 1.5gbit/s вполне через loopback по сокетам проливается и не особо нагружает x86 железку

Я же написал, что это арм. Копирование данных в шаред-мемори занимает 10ms. По сокету будет быстрее? Думаю, нет.

А flock на fd от sem_open можно поставить? Это будет работать как я ожидаю?

Для кольцевого буфера и случая «один производитель - один потребитель» даже синхронизация на x86 не нужна, на ARM барьеров будет достаточно.

Без понятия.

Хотя погоди. Разве sem_open возвращает файловый дескриптор? Там же указатель на структуру, внутренний формат которой не специфицирован.

Я не то написал. Не sem_open, а shm_open. Он возвращает fd.

В линуксе, вроде бы, нет системного вызова для реализации shm_open(), так что там создаётся файл в /dev/shm. Хоть он и не на диске, это файл, поэтому flock() должен работать.

Надо поэкспериментировать. Там даже ftruncate работает, так что должно, наверное.

Странный вывод, но могу и относительно него ответить. Я предлагаю писать код так, чтобы не пришлось писать свою ОС.

Как ты предлагаешь решать проблему принципиальной невозможности освобождения семафора?

- Надо освобождать ресурсы!
- Как?
- Не знаю, как, но надо! Пишите код правильно!
- Как писать-то?
- Правильно! Чо непонятного-то?

Странный вывод, но могу и относительно него ответить. Я предлагаю писать код так, чтобы не пришлось писать свою ОС

Да, потому я пишу под винду.

Вопрос: как организовать межпроцессную блокировку так, чтобы она снималась, если процесс сдох?

Поддерживаю довод грамотного форумчанина о том, что правильным решением будет убирать за собой при внезапном завершении работы процесса.

Каким образом это осуществить? Я бы сначала создал главный процесс-смотритель, а из него уже порождал процессы-потомки: «писателя» и «читателя». В случае отказа в работе одного либо обоих потомков «родитель» прибирает за «детишками» и перезапускает их. Так программа будет работать гораздо надёжнее.

Опции сделать смотрителя нет. Это нормальное требование, когда процессы спаунятся независимо. Просто в посиксе семафоры кто-то сделал через жопу и про SEM_UNDO забыли

Решение для будущих поколений:

На линуксе можно сделать flock() на дескриптор, открытый shm_open().

какого хрена этого нет в посиксе?

Возможно, что объяснение в секции BUGS в man semop:

When a process terminates, its set of associated semadj structures
is used to undo the effect of all of the semaphore operations it
performed with the SEM_UNDO flag. This raises a difficulty: if one (or
more) of these semaphore adjustments would result in an attempt to
decrease a semaphore's value below zero, what should an implementation
do? One possible approach would be to block until all the semaphore
adjustments could be performed. This is however undesirable since it
could force process termination to block for arbitrarily long periods.
Another possibility is that such semaphore adjustments could be ignored
altogether (somewhat analogously to failing when IPC_NOWAIT is specified
for a semaphore operation). Linux adopts a third approach: decreasing the
semaphore value as far as possible (i.e., to zero) and allowing process
termination to proceed immediately.

Предлагаю обернуть сервера и клиента в плагины gstreamer.

Gstreamer в этой схеме нужен только для управления ресурсами. Если мне приспичит сделать мастер-процесс, я и сам его могу написать.

Кто-то уже делал что-то очень-очень похожее на libmdbx (в режиме MDBX_UTTERLY_NOSYNC | MDBX_WRITEMAP, since durability не нужно). Гарантированно быстрее сокетов и надежнее велосипедов.

Либо посмотрите как там сделана синхронизация и recovery при помирании процессов (есть на мьютексах, на семафорах и т.д.). Но imho проще взять как ACId как есть.

Если тебе нужен примитив мьютекса, а не полноценного семафора. Обычный pthread_mutex c включенными атрибутом robust должен помочь. Но там есть своя специфика. Надо читать документацию.

Если тебе нужен примитив мьютекса, а не полноценного семафора. Обычный pthread_mutex c включенными атрибутом robust должен помочь. Но там есть своя специфика. Надо читать документацию.

Менее очевидное решение - сделать таймаут взятия семафора на сервере. Если попытка взять семафор длится больше секунды, то вероятно клиент сдох и можно считать, что семафор взят. Здесь есть логичная проблема: если клиент не сдох, а просто тормозил по неизвестной причине, то в какой-то момент он вернет свое значение и семафор вместо значений 0 и 1 будет использовать 1 и 2.

Может не мучится и вместо семафора использовать транзакции?

Блокчейн, машин лёрнинг, сноубординг, дискотека?

Если попытка взять семафор длится больше секунды, то вероятно клиент сдох и можно считать, что семафор взят.

По моему гадание на гуще. Добавить явный запрос «ты живой?» «да я жив!» и всё. А если ответа нету то подох ибо обязан отвечать. Как сделать запрос вопрос десятый, главное что-бы всё явно было, а не может отвалилося, а может нет.

Ну так о том и речь, что решение плохое. Я в итоге сделал flock() и доволен, а на состояние клиента в принципе плевать.

Аааа, ну тахда хнопочху решено прожать надобно вам дабы возбуждать умы господ залётных.

Спасибо, прожал.

прожал.

Блин прочёл как проржал даже пичку оформил https://i.ibb.co/zX61dFt/image.png эх :D

Надо такую же про дупапрог сделать. Предлагаю перекатиться в те треды, чтобы не оффтопить тут.