URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 65445
[ Назад ]

Исходное сообщение
"Несколько процессов, но один файл"

Отправлено tian , 06-Апр-06 17:34 
Вот столкнулся с такой несколько логической задачей:
Исполняется несколько процессов, порожденных одним родительским.
Им необходимо вести некую статистику (у всех процессов одни критерии) и сбрасывать все в один файл.
Как реализовать, чтобы они все-таки могли блокировать и записывать все в один файл ?
Понятно, что если назругка мала, то можно блокировать файл и писать туда (точнее, сначала считать, прибавить свои накопленные значения и записать).
Но встает вопрос  - а если много процессов ?
блокировать и если неудачно, то потом через случайный промежуток времени снова пробовать, а пока все это хранить в памяти ?
Но ведь может получиться, что он так и не дождется блокировки файла.
Какие могут быть архитектурные решения данной проблемы ?

Содержание

Сообщения в этом обсуждении
"Несколько процессов, но один файл"
Отправлено Hamper , 06-Апр-06 17:46 
Не изобретай велосипед! Syslogd уже давно изобретен :)

"Несколько процессов, но один файл"
Отправлено tian , 06-Апр-06 17:58 
>Не изобретай велосипед! Syslogd уже давно изобретен :)

В принципе да, но ведь тут нужно не только отправить, но и получить данные.
Хотя суммирование можно и возложить на что-то похожее syslog.
Но тут придется держать еще один процесс.
Я согласен, сделать можно, отправляя текущее значения в сокет.
А если понадобиться в зависимости от полученных значений сделать некоторые действия ?
Все-таки хотелось бы рассмотреть вопрос о выполнении данной задачи в рамках одного процесса.
Я и говорю, что это несколько теоретический вопрос.
Хотя кажется да, единственно возможный вариант - сокет. А уж далее сокет будет следить за тем, чтобы данные были корректны. Например, всем выдавать сразу значения текущие, но держать стек запросов. И потом когда процессы будут возвращать значения измененные (это числа, которые только увеличиваются, пока что), смотреть, что раньше или позже отправлено и корректировать общее значение.
Но может быть есть другие решения ?


"Несколько процессов, но один файл"
Отправлено MoHaX , 07-Апр-06 04:59 
>>Не изобретай велосипед! Syslogd уже давно изобретен :)
>
>В принципе да, но ведь тут нужно не только отправить, но и
>получить данные.
>Хотя суммирование можно и возложить на что-то похожее syslog.
>Но тут придется держать еще один процесс.
>Я согласен, сделать можно, отправляя текущее значения в сокет.
>А если понадобиться в зависимости от полученных значений сделать некоторые действия ?
>
>Все-таки хотелось бы рассмотреть вопрос о выполнении данной задачи в рамках одного
>процесса.
>Я и говорю, что это несколько теоретический вопрос.
>Хотя кажется да, единственно возможный вариант - сокет. А уж далее сокет
>будет следить за тем, чтобы данные были корректны. Например, всем выдавать
>сразу значения текущие, но держать стек запросов. И потом когда процессы
>будут возвращать значения измененные (это числа, которые только увеличиваются, пока что),
>смотреть, что раньше или позже отправлено и корректировать общее значение.
>Но может быть есть другие решения ?

Может СУБД какую-нить прикрутить?


"Несколько процессов, но один файл"
Отправлено satelit , 07-Апр-06 05:13 
А добавь еще один свой процесс (или нить в рамках одного процесса), и скидывай ему данные, а он пусть их пишет, сортирует, в общем обрабатывает.

"Несколько процессов, но один файл"
Отправлено tian , 07-Апр-06 08:20 
Я немного поясню:
Есть процесс  слушает входящие соединения на сокете. Ну и ес-но порождает другой процесс, если соединение есть. Тот процесс порождает еще один и затем еще (по конвейеру).
Так вот тот последний (четвертый процесс) процесс должен считать данные (ну или получить их как-то) (статистика счетчиков различных), прибавить (или убавить) от текущих полученных счетчиков свои значения и снова их записать.
Процессы порождаются почти случайно (нет закономерности), поэтому случай гонки очень даже может быть.
Необходимо, чтобы между считыванием данных и записью новых значений другие процессы не могли вмешаться. Но вот очередность их может быть малость в принципе нарушена (в зависимости от даты рождения процесса, т.е. первый родившийся процесс может в принципе и вторым начать обрабатывать данные.
Если блокировать файл - то можно относительно долго ждать получение ресурса (и хотелось бы эту процедуру вынести за рамки других процессов), либо если вдруг процесс зависнет, то другие уж не смогут получить ресурс.
БД прикручивать неохота - слушком задача не та для решения при помощи БД. Да и смысл все-равно остается тот же.
Видимо - все-равно должен присутствовать процесс-регулировщик, имеющий стек. В него сыплятся запросы на ресурс, он их ставит в очередь и выдает разрешения на доступ ресурса. Ну и ес-но имеющий таймер на ожидание освобождения ресурса, если что - принудительно освобождать ресурс и давать другому.
Просто как я и говорил - эта задача скорее архитекрутного решения, теоретическая (хотя в действительности ее необходимо реализовать на практике).

Вот satelit  я так полагаю, тоже склонен к такому подходу, только нить организовывать сложно, так как придется модифицировавть сам процесс. А вот сторонний процесс реализовать проще и надежнее.