Да нет же
в среднем система знает сколько тактов свободного времени остаётся на потоки приложений (т.е. после отработки прерываний, диспетчера задач).
Далее запускаются приложения, которые требуют выполнения в каждом такте (опрос клавиатуры и т.п.) [я считаю что это и есть процессы высшего приоритета - приоритета реального времени; потоки реального времени ВСЕГДА должны успевать отрабатываться раньше прерывания, т.е. оставлять процессорное время на другие потоки]. И только после этого начинают отрабатывать остальные процессы.
Согласен, точно никак померять длительность каждого потока не получится, но вот менеджер процессов может сделать косвенно.
Вот такой алгоритм:
При выполнении на текущем прерывании набора процессов может оказаться два варианта:
- Потоки отработали раньше, чем пришло прерывание, в таком случае можно говорить что требование кооперативной многозадачности выполнено - все задачи выполнились вовремя и никаких проблем нет, здесь вопрос длительности даже не стоит принципиально.
- Потоки не успели отработать
В таком случае ветвление:
А) Не успел отработать 1 поток - скорей всего он и является критичным (но вовсе не обязятельно он, это выясняется на протяжении нескольких прерываний), его приоритет слегка занижается, это скажется на первоочерёдности его вызова (переключения на него) при очередном вызове. Постепенно самый "дурной" поток уйдёт в фоновый режим.
Б) Не успели отработать несколько потоков - в таком случае происходит миксирование потоков до тех пор, пока количество отработанных за прерывание потоков не станет максимальным (т.е. чисто практическим методом вытесняем наиболее критические потоки, которые нарушают требования кооперативности). Т.е. рассматривая динамику, скажем, за 10 прерываний можно уже более менее чётко определить какой из потоков жрёт больше всего времени.
Вот пример
Потоки Время (тактов)
0 ______ 2500
1 ______ 5000
2 ______ 10000
3 ______ 15000
4 ______ 20000
5 ______ 25000
6 ______ 30000
Количество свободных тактов процессорного времени - 65000.
Первая схема запуска (на первом прерывании):
6, 5, 4, 3, 2, 1, 0 (расстановка от большего приоритета к меньшему)
В итоге успели выполниться 6, 5 и частично 4й поток.
Система делает микширование потоков (вторая схема запуска)
6, 5, 3, 2, 1, 0, 4
В итоге выполнились 6, 5 и частично 3й поток
Очередное микширование (3ья схема)
6, 5, 2, 1, 0, 4, 3
В итоге выполнились 6, 5, 2 и частично 1й поток (т.е. количество выполненных потоков увеличилось).
Теперь система делает микширование на поток 5 аналогичным образом она придёт к схеме:
6, 2, 1, 0, 4, 3, 5
Выполнились 6, 2, 1, 0 и частично 4й поток (опять увеличение)
Теперь очередь за 6м потоком:
2, 1, 0, 4, 3, 5, 6
В итоге выполнились 2, 1, 0, 4, 3 и частично 5й поток.
Т.о. 6й поток и 5й оказались в самом конце схемы (менее приоритетные), в то время как потоки 2, 1, 0, 4 и 3 получили больший приоритет, т.к. они укладываются в одно прерывание.
В общем то предложенная схема не лишена недостатков, однако показывает что не всё так плохо как кажется и косвенными методами можно вычислить нарушителей режима (которые кушают слишком много времени).
Тут есть ещё такое замечание.
Потоки реального времени тоже могут поддвергаться дисциплинарным санкциям, если вдруг они ещё работали когда пришло новое прерывание.
И ещё, на самом деле вычисление "дурацких" потоков, нарушающих режим будет приходить гораздо быстрей.
Это связано с тем, что только потоки реального времени выполняются каждое прерывание.
А остальные процессы (в зависимости от изначального и подкорректированного системой приоритета) будут выполняться чаще или реже, но всё же не каждое прерывание.
Т.е. скажем из приведённой схемы 6й поток - самый жёсткий для нашей системы - (для примера) может быть не выполнен системой на 5ое прерывание. И в это прерывание диспетчер потоков зафикисирует факт значительного увеличения количества выполненных потоков. Естественно после некоторых вычислений диспетчер определит что это именно 6й поток является нарушителем (кушает почти половину процессорного времени) и "одарит" этот поток самым низким приоритетом.
Правда возникают следующие сложности: такие длинные потоки будут делиться на несколько частей: начальная, промежуточные и последняя (т.е. он прерывается несколько раз) первая и промежуточные естестенно будут "кушать" всё процессорное время. А вот последняя часть может оказаться очень короткой, изза чего диспетчер потоков может принять ошибочное решение о увеличении приоритета такого потока, что впрочем на следующем же вызове будет отменено. Кроме указанной ошибки есть такая ошибка (это наверное заметил для себя каждый), не все процессы имеют фиксированное время исполнения.
А в общем такая схема устраивает на 90%...
Ответить с цитированием