Как использовать файлы в /var/lock ?

Проверяешь, есть ли lock файл.

Если нет быстренько создаёшь свой и пишешь свой PID.

Если есть читаешь из него pid и проверяешь есть ли такой процесс. Если нет пишешь свой pid.

Если чужой pid всё-таки есть вываливаешься с криками «что вы мне подсовываете занятый ресурс!!11 А?»

Наверняка есть метод, делающий это всё атомарно.

Ясно.. а я то думал...

Я ради интереса делаю что то вроде шины, приложение должно читать данные из одного pipe и посылать его во множество других, то есть делать широковещательную рассылку. Но проблема в том что если одновременно 2 приложения пошлют в pipe строку, то 2 строки смешаются. И сигнал не будет правильно передан. Я хочу сделать так что бы каждое приложение на время ввода строки могло монополизировать поток.

http://rus-linux.net/MyLDP/BOOKS/Moduli-yadra-Linux/06/kern-mod-06-22.html

Проверяешь, есть ли lock файл.

Я, кстати, неоднократно встречал утверждения, что это одно из самых больших уродств в Unix. Почему?

Я, кстати, неоднократно встречал утверждения, что это одно из самых больших уродств в Unix. Почему?

Потому что pid-ы не уникальны и могут повторяться.

Если нет быстренько создаёшь свой и пишешь свой PID.

Если есть читаешь из него pid и проверяешь есть ли такой процесс. Если нет пишешь свой pid.

Не «быстренько пишешь свой pid», а создаешь временный файл со своим pid-ом и переименовываешь его в нужный lock-файл. Операция переименования атомарна.

имхо еще из-за неатомарности

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

а кто захавал файл можно получить через lsof/fuser, необязательно писать в него пид

Если строки меньше PIPE_BUF (4096 байт в linux), то запись атомарна.

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

То есть если строка всего в 4 килобайта то можно не заморачиваться? Радует. Мне надо просто пересылать сообщения:

service daemon-e started
service daemon-e stoped
service daemon-e reload-conf
system status reboot
meta-system-status base-system start

А почему в треде нема отсылок к fcntl FD_SETLK? Не модно что ль.

В момент времени уникальны.

если одновременно 2 приложения пошлют в pipe строку, то 2 строки смешаются.

если строки меньше 64К, то не смешаются. А если больше, то что-ты ты не так делаешь…

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

дык смотри, кто файл открывает. Если файл кто-то уже открыл, жди, пока закроют. Файл сам по себе может работать семафором.

Да, можно не заморачиваться. Почитай pipe(7), раздел PIPE_BUF.

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

Что в итоге у Вас получилось?

Что в итоге у Вас получилось?

Я отказался от этого проекта и продолжил делать другой.

Можно еще немного вас поспрашивать? Вы пересмотрели архитектуру (принцип) совместного использования ресурсов или вообще больше не пишете в этом плане (т.е. тема просто закрыта и все)?

Вы пересмотрели архитектуру (принцип) совместного использования ресурсов или вообще больше не пишете в этом плане (т.е. тема просто закрыта и все)?

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

Благодарю! Полностью с Вами согласен. Спасибо за отклик!