OSDev

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

Нет. Имел ввиду именно невытесняющую кооперативную многозадачность на основе тех же сопрограмм или активных объектов. Я их упомянул выше.

У меня есть приоритет system real time, который по сути реализует кооперативную многозадачность внутри ядра. Потоки с этим приоритетом могут быть вытеснены только системным потоком менеджера процессов, активируемым только в режиме ручного управления.

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

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

Фантом, а в чём приоритет-то? Вытесняемыми потоки из невытесняемых не получится сделать прозрачно, скрыв всё "в ядре". Как минимум придётся явно в коде потоков объявлять функции захвата мутексов или отправки синрхонизирующих сообщений. А если вытеснение необязательно, то всё можно скрыть в языке. Например, реализавав всё в виде сопрограмм...

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Yoda,
Используем сторожевой таймер и нет проблемы.

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

Для однопроцессорных систем это естественно.

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

Способ не плох и не хорош, просто позволяет экономить несколько байт на контекст задачи и несколько тактов на переключение. Это актуально только в каких-то невероятно жёстких условиях, что весьма специфично. Для PC не потребно.