Вытесняющая многозадачность (диспетчер mzkernel)

[Barmaley_m]

Извини, но это бред.

Прошу заметить, я тебя не оскорблял.

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

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

Несмотря на то, что без вытеснения по прерываниям работа системы будет в некоторой степени детерминированной (наподобие кооперативной многозадачности), отсутствие знаний о работе хотя бы одного из потоков превращает работу такой системы в недетерминированную, когда каждый конкретный поток не знает, когда у него заберут процессорное время. Например, в моем диспетчере поток, устанавливая объект "Event", не знает, будет ли он при этом вытеснен. Это зависит от того, ожидает ли сигнализации этого объекта другой поток с более высоким приоритетом.

Ну и да, в моем диспетчере поддерживается вытеснение и по прерываниям, если в процедуре их обработки будут вызываться функции вида "SetEvent".

Даже если мы будем "вытеснять" задачу сами в пределах ядра при вызовах функций ядра - всё равно это будет де факто кооперативная многозадачность, просто кооперативность будет обеспечиваться ядром,

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

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

"Настоящие" современные ОС тоже не переключают контекст потоков без необходимости. Это дорогая операция. Зачем жечь время процессора зря? Даже переключение по таймслайсам для реализации Round-Robin псевдопараллельного исполнения использует интервалы времени, сравнимые или превышающие 1/50с.

Основное применение шедулера на ZX, как мне видится, это возможность в фоне считать "длинные" и вспомогательные задачи, параллельно исполняя основные, которые отрисовывают результат.

В этом смысл многозадачности вообще, а не только на ZX. Длительная работа в режиме Round-Robin - это плохая ситуация даже на современных "больших" ОС, так как каждая задача при этом работает медленнее, чем хотелось бы.

Никто, опять же, не мешает запихать принудительную кооперативность в некие системные вызовы ядра - и получим примерно то, что сделано в твоём планировщике

Нет, получим не то, что сделано в моем планировщике, а Windows 3.11. Это там была "принудительная кооперативность" при вызове функции GetMessage или PeekMessage, а в других ситуациях контекст не переключался.

То, что сделано у меня - это переключение контекста по событиям, которые, по принятому принципу работы, являются основаниями для смены контекста. Быстро и максимально отдать время процессора приоритетным (важным) потокам; когда они чего-то ждут, например, нажатия клавиши - отдать время остальным.

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

Точно так же сделано в реальных больших ОС. Я разрабатывал диспетчер после долгого и подробного курения исходников ReactOS (аналог Windows). Там, конечно, реализовано больше, чем у меня - но не в один день Москва строилась; и не все из этого нужно на ZX.

Почему настоятельно советую попробовать взять мой планировщик - собственно по двум причинам: а) он сильно оптимизирован; б) он умеет то, что жизненно необходимо ZX - хотя бы приблизительную синхронизацию с экраном.

Хорошо, спасибо. Обязательно поизучаю!