LINUX.ORG.RU

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

 ,


0

1

Имеется однопроцессорная система. Есть несколько однотипных процессов(2 или более). У каждого из процессов есть суперцикл. Нужно сделать так чтобы каждый процесс выполонял весь свой суперцикл только определенное колличество раз и отдавал процессорное время другому процессу. т.е. выполняться они должны последовательно. При этом колличество циклов у разных процессов может быть разным и может меняться с течением времени.

Можно изобразить работу 3-х процессов так:

 (***)->(**)->(****)-\
^                     |
\____________________/
где * - оборот цикла, () - отдельный процесс.

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

Второй случай когда несколько процессоров или ядер я пока не рассматриваю.

Ответ на: комментарий от andreykyz

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

true_admin ★★★★★
()
Ответ на: комментарий от andreykyz

Если процесс зависнет например на системной функции read(..). Что кстати бывает часто. В такой ситуации нужно чтобы в следующий процесс всё же начал работать

В момент зависания на read? Такое умеет только системный планировщик.

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

Кхм. Это произойдет _сразу_, потому что процесс перейдет в состояние ожидания ввода-вывода.

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

Да, за исключением того, что я не понимаю такой любви к FIFO и сделал бы это на сокетах.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от andreykyz

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

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

tailgunner ★★★★★
()

выполняться они должны последовательно

В смысле они должны по цепочке передавать какие-то данные?

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

Вообще ничего не понял, а чем тогда не устраивает обычный планировщик?

Выполняться последовательно должен только важный участок кода.

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

no-such-file ★★★★★
()
Ответ на: комментарий от andreykyz

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

Ну так в чем проблема? Есть процесс 1, он залип на read и стоит. Есть процесс 2, он работает с другим источником данных и не залип - передает данные. Что вас не устраивает?

no-such-file ★★★★★
()
Ответ на: комментарий от true_admin

true_admin

Так, настало время рассказать задачу. А то всё как-то очень теоретизированно.

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

andreykyz ★★
() автор топика
Ответ на: комментарий от no-such-file

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

andreykyz ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.