Задачка для размышления. Планирование работы нескольких процессов.

Если процессы готовы сотрудничать - сделай передачу токена.

Что значит готовы сотрудничать?

Это значит, что они знают о существовании друг друга и могут это использовать, в частности, передавать токен.

в обычных ОС (linux, оффтопик, BSD) планировщик сам решает, кому, когда и сколько процессорного времени отдать

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

в обычных ОС (linux, оффтопик, BSD) планировщик сам решает, кому, когда и сколько процессорного времени отдать

Есть же SCHED_FIFO/SCHED_RR

Есть же SCHED_FIFO/SCHED_RR

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

Так я и не спорю. Мой коммент был к «планировщик сам решает, кому, когда и сколько процессорного времени отдать». С SCHED_FIFO это все вполне контролировать можно.

Понял, это моя матчасть хромает. Только, на сколько я понял, FIFO отдаст управление на первом же IO. Это не есть гуд.

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

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

а кто мешает тупо запускать процессы последовательно по одному? Постановка задачи весьма туманная. То ли автор проектирует нечто новое, то ли хочет допилить существующее, то ли приделать внешние костыли к закрытому говнокоду

Только, на сколько я понял, FIFO отдаст управление на первом же IO. Это не есть гуд.

Если не блокироваться, обычные процессы вообще времени не получат :)

Советую Стивенса прочитать (UNIX: взаимодействие процессов). Тогда будет понятно все.

Если не блокироваться, обычные процессы вообще времени не получат :)

sched_yield же. Ну и, на сколько я понял (могу наврать), rt-процессы и обычные шедулятся по-разному. Т.е. SCHED_FIFO действует только на процессы сделавшие sched_setscheduler(SCHED_FIFO|SCHED_RR)

sched_yield

Не, не поможет. Запланируется следующий процесс в очереди, если его нет, то управление вернется к процессу, вызвавшему sched_yield

Ну и, на сколько я понял (могу наврать), rt-процессы и обычные шедулятся по-разному. Т.е. SCHED_FIFO действует только на процессы сделавшие sched_setscheduler(SCHED_FIFO|SCHED_RR)

ну да. дефолтный алгоритм SCHED_OTHER

если его нет, то управление вернется к процессу, вызвавшему sched_yield

так всё правильно, это значит что у нас только один процесс исполняется :)

так если процессы могут существовать вместе и им нужно поочередно поработать с каким-то критичным ресурсом, то flock() должен спасти отца русской демократии

Мой коммент был к «планировщик сам решает, кому, когда и сколько процессорного времени отдать». С SCHED_FIFO это все вполне контролировать можно.

...в пределах одного уровня приоритетов.

Если не блокироваться, обычные процессы вообще времени не получат :)

sched_yield же.

Счиатй, что sched_yield игнорируется более-менее новыми планировщиками.

В общем, только передача токена. Закольцевать процессы pipe'ом, и передавать байт том, чья очередь работать.

Это нужно для железки с кооперативной многозадачностью без таймера?

sched_yield игнорируется более-менее новыми планировщиками.

Знаешь, я вижу что каждый год поведение этого системного вызова меняется. До введения SCHED_FIFO он вообще долгое время игнорировался. А щас в мане даже рекомендуют его использовать O_o (см. man). В общем, я так понимаю что sched_yield на линуксах имеет смысл только с sched_setscheduler.

В общем, только передача токена

я согласен, остальное как-то... ненадёжно.

До введения SCHED_FIFO он вообще долгое время игнорировался.

Ты не можешь быть настолько старым, чтобы застать времена «до введения SCHED_FIFO».

А щас в мане даже рекомендуют его использовать O_o (см. man)

Наверное, у меня старые маны.

Что значит готовы сотрудничать?

Использовать ipc

Обмениваться сигналами или использовать синхронизирующие объекты.

Допиливаю существующее приложение которое работает с сетью.

т.е. мне просто нужно установить планировщик SCHED_RR (т.к. в отличии от SCHED_FIFO следит за квантом времени). И когда процесс выполнит определенное кол-во циклов, мне просто нужно будет вызвать sched_yield() ???

Интересно тогда каким образом это будет работать на нескольких физических ядрах О_о.

EugeneBasтак

если процессы могут существовать вместе и им нужно поочередно поработать с каким-то критичным ресурсом, то flock() должен спасти отца русской демократии

Спасибо, я уже синхрюcь при помощи nptl .

т.е. мне просто нужно установить планировщик SCHED_RR

вот так нужно: Задачка для размышления. Планирование работы нескольких процессов. (комментарий) . На шедулер не надейся, слишком легко тут налажать. Сделай явную передачу управления.

каким образом это будет работать на нескольких физических ядрах О_о.

У каждого ядра своя очередь на сколько я понял. в гугле можно найти про это информацию из которой следует... что это всё игры с огнём.

А вообще ты сам говорил что у тебя задача с одним ядром :)

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

true_admin

А вообще ты сам говорил что у тебя задача с одним ядром :)

ЭЭЭ. На самом деле есть 2 устройства одно встаиваемое с одним ядром arm и mips устаройства, а второе устройство это сервер например с 4-х ядерным AMD.

tailgunner

В общем, только передача токена. Закольцевать процессы pipe'ом, и передавать байт том, чья очередь работать.

т.е. все открывают на чтение pipe. А потом когда один процесс отработает, то он пишет туда байт все его select'ят и у кого очередь пришла идет дальше, а все остальные опять селектить. Так????

т.е. все открывают на чтение pipe.

Не понял этой фразы. Процессы объединяютс в кольцо через несколько pipe'ов (по количеству процессов), у каждого есть входной и выходной pipe.

А потом когда один процесс отработает, то он пишет туда байт все его select'ят и у кого очередь пришла идет дальше, а все остальные опять селектить. Так????

Если «туда» == «в свой выходной pipe», то да.

Но, наверное, это не единственая схема передачи токена.

Предлагаю счётчик по модулю N! :)

Предлагаю счётчик по модулю N! :)

И животноводство!

В смысле? :)

Вообще, я бы сделал арбитра процессов который бы управлял процессами.

В смысле? :)

В смысле Стругацких^W использовать слово «животноводство"как токен.

Вообще, я бы сделал арбитра процессов который бы управлял процессами.

Если это родительский процесс, то проще сделать кольцевой pipe (и юниксвейнее, кстати); если не родительский... там тоже проще всего будет изобразить передачу токена.

Всё, понял, процессы однотипные.

Я думал что они разной природы и тогда в каждой проге пришлось бы хардкодить вызов последующей... Или ты имеешь в виду написать в шелле prog1 | prog2 | prog N ? Вариант. А как замкнуть pipe? Через FIFO?

У меня вот так вот:

rm /tmp/cycle; mkfifo /tmp/cycle
echo 1 > /tmp/cycle & # kickstart

function worker { while true; do read; sleep 1; echo "worker $1 done" > /dev/stderr ; echo -e "token"; done }
cat /tmp/cycle | worker 1 | worker 2 | worker 3 > /tmp/cycle

Я думал что они разной природы

Природа процессов не играет роли, хотя я подозреваю, что все они выполняют одну программу.

в каждой проге пришлось бы хардкодить вызов последующей...

Смотря что называть «хардкодом». В любом случае, после нужного числа итераций «суперцикла» должен быть вызов чего-то.

Или ты имеешь в виду написать в шелле prog1 | prog2 | prog N

Я предполагал Си-программу и так сразу не скажу, как в шелле написать кольцевой pipe.

У меня вот так вот:

Если стоит задача обойтись только шеллом, и разрешено использовать для передачи токена stdin и stdout - вполне подойдет.

Есть одна проблемка с этим токеном. Если процесс зависнет например на системной функции read(..). Что кстати бывает часто. В такой ситуации нужно чтобы в следующий процесс всё же начал работать. В планировщике SCHED_RR это, по идее, должно произойти из-за того что у «залипшего» процесса законцится квант времени. А как токенами это хз.

С другой стороны если есть арбитр. Вы предлагаете сделать следующее: Процесс отработав нужное ему колличество циклов пишет в fifo файл планировщика и начинает селектить свой fifo файл, а в нужное время планировщик пишет в этот файл байт начиная селектить свой fifi и процесс просыпается.

Типа того?

Если процесс зависнет например на системной функции read(..)

с чего он должен зависнуть? Токен из кольца исчезнет? :) Или ты имеешь в виду баг в программе и повисон? Ну это уже задача программиста чтобы внутри суперцикла прога не глючила.

Как раз SCHED_RR и не подходит по этой причине: любое IO внутри суперцикла приведёт к переключению задачи.

Но я согласен, схема не fail-over, любое падение прибьёт всю цепочку.

Кстати, тут шелл выполняет роль составителя пайплайна. А на сях как замкнуть пайп без внешних скриптов и без арбитра или вспомогательной программы?

true_admin

с чего он должен зависнуть?

Да очень просто, делаешь ifconfig eth0 down(главное после вызова select). И процесс залипает на функции read(...) примерно на секунду, после чего получает EINTR . Который я ловлю и обрабатываю. Но на данный момент конкурирующий процесс может выполнится за это время много раз, т.е. заменить собой оборвавшийся канал связи.

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

т.е. эти процессы агрегируют несколько каналов связи. Надеюсь я понятно объясняю.

true_admin

А на сях как замкнуть пайп без внешних скриптов и без арбитра или вспомогательной программы?

насоздавать файлов fifo? :-D

Да очень просто, делаешь ifconfig eth0 down(главное после вызова select). И процесс залипает на функции read(...) примерно на секунду, после чего получает EINTR . Который я ловлю и обрабатываю. Но на данный момент конкурирующий процесс может выполнится за это время много раз

так сказано же пока идёт супер цикл никаких переключений! Пусть хоть астероид на землю падать будет, хоть сисадмин ifconfig передёрнет, пока суперцикл не завершится другой процесс не имеет права работать. Именно по этой причине нельзя слепо надеятся на SCHED_RR, порядок работы процессов должен задаваться явным образом.

насоздавать файлов fifo? :-D

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

true_admin

Как раз SCHED_RR и не подходит по этой причине: любое IO внутри суперцикла приведёт к переключению задачи.

хм. а мне как раз надо упорядочить момент записи в сеть (write(..)). И честно говоря не догоняю переключение при IO это плохо или хорошо. О_о

true_admin

Пусть хоть астероид на землю падать будет, хоть сисадмин ifconfig передёрнет, пока суперцикл не завершится другой процесс не имеет права работать.

Нет немного не так, в случае если канал с которым работает процесс тупит, он всё-таки должен передать управление. Иначе как ты сказал не fail-over

я не понимаю что ты делаешь, но... зачем упорядочивать? Может принимающая стороная сама отсортирует в нужном порядке?