context switcher in new OS?

[Alex/AT]

но это чревато рассинхронизацией процессов реального времени

Абсолютно прав. При вытеснении задач в RTK (практика) происходит легкая рассинхронизация, причем ее степень зависит от продолжительности прерванного таска.

то необходимо это дело слегка уложнить

Да, очевидно придется сделать метод текущего определения таском своего времени. Я предполагаю завязать под это дело регистр IY (его нельзя будет использовать ВООБЩЕ, за исключением прямого назначения). Это увеличит и расходы тактов на планирование, и сложность диспетчера. И еще отнимает один регистр совсем... Так что вариант ли?

[Advertiser]

[Vitamin]

Абсолютно прав. При вытеснении задач в RTK (практика) происходит легкая рассинхронизация, причем ее степень зависит от продолжительности прерванного таска.

значит, нужно делать так, что процессы реального времени могут вытеснить текущий процесс, в какой бы он фазе ни находился. опять-таки, за исключением тех ситуаций, когда происходит запрет прерываний (или флаг отложенности прерываний), но это должно происходить _только_ во время процедуры пропуска кванта. т.о. процессы реального времени все равно будут вызваны в данный квант, правда с небольшим смещением от начала инта. не очень критично, потому как это смещение обычно не превысит +200-300 тактов от стандартного

Да, очевидно придется сделать метод текущего определения таском своего времени. Я предполагаю завязать под это дело регистр IY (его нельзя будет использовать ВООБЩЕ, за исключением прямого назначения). Это увеличит и расходы тактов на планирование, и сложность диспетчера. И еще отнимает один регистр совсем... Так что вариант ли?

не вариант. еще больше увеличивается уязвимость системы. прямо как бейсик получается- испортил iy или hl' и гудбай америка! %)

[Alex/AT]

но это должно происходить _только_ во время процедуры пропуска кванта

Хм... Нелогично. Во время процедуры пропуска кванта ТЕКУЩИЙ процесс всегда вытесняется, если есть ожидающие кванта процессы. А вот если начинаем вытеснять процесс по приходу прерывания - встает трабла. Невозможно узнать, сколько тактов процесс отработал. Поэтому внутренний счетчик тактов "уходит", и происходит легкая рассинхронизация.

[Vitamin]

Хм... Нелогично. Во время процедуры пропуска кванта ТЕКУЩИЙ процесс всегда вытесняется, если есть ожидающие кванта процессы. А вот если начинаем вытеснять процесс по приходу прерывания - встает трабла. Невозможно узнать, сколько тактов процесс отработал. Поэтому внутренний счетчик тактов "уходит", и происходит легкая рассинхронизация.

не вижу ничего нелогичного. процесс имеет право запретить прерывания (сиречь возможное принудительное вытеснение) исключительно если сам собирается это сделать. типа "не трогайте меня, сам все отдам!" %)

[GriV]

Средняя длительность одного кванта около 5 мсек.

Чем мерять собираешься?

Она меряется статистическими методами - если она длится больше, то скорей всего она часто будет попадать на прерывание (т.е. прерывание пришло во времся работы потока). Для такого потока система будет применять штрафные санкции смещения потока вниз по приоритету.

[GriV]

Сообщение от GriV
2. Классический подход. Обработчик прерываний и диспетчер потоков разные программы, взаимодействующие по классическим правилам. В этом случае никаких проблем нет.

Это с какого он 'классическим' стал? =)

Проблем нет, так как ты по сути предложил откладывать прерывания, когда их можно пропустить. Все красивые и сказанные с гордым выражением слова не изменяют сути =)

Классическим он стал с тех пор как создатели ОСей подбили шишек в процессе разработки указанного предмета.

Нет я не откладываю прерывания, просто я на прерывания ложу несколько иные функции.

[GriV]

(задача в общем то стоит не в этом, но это не так важно), то тогда конечно же должна стоять задача жёсткой синхронизации.

У нас же (исходя из того что есть) стоит задача создания системы с кооперативным делением процессорного времени.

В таком случае (есть такое положение), что обеспечить самый высокий приоритет система может лишь для прерывания. Любой поток (даже обладающий самым высоким приоритетом) будет всегда обладать в общей схеме низким приоритетом. А значит весьма возможно возникновение рассинхронизации.

[lvd]

Классическим он стал с тех пор как создатели ОСей подбили шишек в процессе разработки указанного предмета.

Угу, стало быть амигаос не классическая, а модерновая. =)

Нет я не откладываю прерывания, просто я на прерывания ложу несколько иные функции.

Угу... А ещё ты кооперативную вместо вытесняющей делать хочешь, и даже мерять время работы процессов непойми чем =)

[Corpsegrinder]

А ты чем на спектруме собрался мерять время работы процессов?
У меня на ум приходит только разве что посчитать сколько уже от начала работы поршло прерываний. Ну можно ещё, поручить каждому порцессу честно призначаться сколько он тактов отъел. Можно условно периодичностью вызовов время посчитать, только это будет время не реальное, а условное в рамках колебательных характеристик текущего состояния ОСи.

[GriV]

в среднем система знает сколько тактов свободного времени остаётся на потоки приложений (т.е. после отработки прерываний, диспетчера задач).
Далее запускаются приложения, которые требуют выполнения в каждом такте (опрос клавиатуры и т.п.) [я считаю что это и есть процессы высшего приоритета - приоритета реального времени; потоки реального времени ВСЕГДА должны успевать отрабатываться раньше прерывания, т.е. оставлять процессорное время на другие потоки]. И только после этого начинают отрабатывать остальные процессы.
Согласен, точно никак померять длительность каждого потока не получится, но вот менеджер процессов может сделать косвенно.

Вот такой алгоритм:

При выполнении на текущем прерывании набора процессов может оказаться два варианта:
- Потоки отработали раньше, чем пришло прерывание, в таком случае можно говорить что требование кооперативной многозадачности выполнено - все задачи выполнились вовремя и никаких проблем нет, здесь вопрос длительности даже не стоит принципиально.
- Потоки не успели отработать
В таком случае ветвление:
А) Не успел отработать 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%...