OSDev

Если кооп.мн. организовать целиком в отдельном пользовательском потоке, то придётся заниматься активным опросом портов и т.д., что сводит "на нет" преимущества эффективного использования процессора (на это указывал и SII). А можно использовать и обработчики прерываний, которые:
- Перехватывают прерывание, формируют связанное с ним событие и помещают в очередь событий. Опросом очереди событий занимается менеджер событий.
- Либо обработчики выполняют функцию диспетчеров: поток вызывает WaitInt(номер прерывания), и переходит из состояния "исполнение" в состояние "ожидание". Когда возникает прерывание, его обработчик (по совместительству диспетчер) переводит все потоки, ожидающие данного события из состояния "ожидание" в состояние "готов". Дальнейшую судьбу этих потоков решит планировщик (естественно, после того, как получит управление от прерванного обработчиком потока).
Отсутствие внешних по отношению к потокам механизмов синхронизации и отсутствие необходимости поддерживать на каждый поток отдельную структуру в ядре, как раз и составляют львиную долю выигрыша в производительности. А что касается сложности реализации: всё зависит от подхода и инструмента. Если делать кооперативную систему с оглядкой на систему с вытеснением, то лучше сразу делать систему с вытеснением:) В кооперативной системе нет "потоков". Есть "акторы", "активные объекты", "конечные автоматы", "генераторы", "протопотоки" и т.д.

Возвращаемся на круги своя. Если у ОС нет возможности переключить задачу, надёжность всей ОС зависит от одной безграмотно написанной задачи. Если есть - это уже не кооперативка.


Так или иначе, планирование времени кто-то должен осуществлять. Либо небольшой единый фрагмент проверенного кода, написанный создателями ОС, либо толпы безграмотных писателей ВСЕГО запущенного прикладного ПО.

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

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

Обработка прерываний не имеет прямого отношения к разделению времени. Это отдельный механизм. А о принципах разделения времени следует почитать отдельно, например у классиков: Танненбаум, Дейкстра, Кнут.. Больше не буду отвечать на подобные заявления. Планированием исполненения "потоков" здесь по-старинке занимается планировщик. А всё остальное, вплоть до записи на диск весьма спорно.

Вообще, читая подобные заявления, начинает складываться мнение, что в современном осестроении не цель определяет средства, а средства цель. Взяли ядро, напхали в него модных явлений, всяких жОсткостей, реальностей, мульти-пульти-поточностей. На то оно и ядро - свалка универсальной логики на все времена. А логика работы системы как-нибудь сама натянется. Она ведь не главная. Дай лесорубу бензопилу, а он скажет: говно твоя бензопила - херово дрова ей рубить, да и ненадёжная - ломается быстро...

Ну так оно так и обстоит. Если в 16-разрядной Винде какая-то задача зависала, висло всё -- по этой самой причине. Хотя можно предусмотреть некоторые средства "реанимации", они не решат проблему кардинально, да к тому же будут жуткими костылями. Посему кооперативная многозадачность не была распространена и ранее, а нынче и вовсе умерла (разве что в каких-нибудь специализированных системах может использоваться).

Средства реанимации и есть костыли. Хоть в кооперативке, хоть в вытесняловке, хоть в медицинской практике. Если есть способ сделать надёжно - костыли не нужны. А узость применения зависит только от узости фантазии.. (А так же инструмента, опыта и ясного представления картины происходящего)

К тому же, некогда кооперативная винда - плохой пример. Судить по ней то же, что: пошёл налево - подскользнулся, упал. Теперь налево не хожу, только направо. Тобишь стереотипно. Тогда разработчики ПО не могли себе представить, что программы можно писать декларативно, возложив реализацию на язык и его компилятор. Кто скажет, что это "не гибко" - пусть пишет оси на ассемблере, ибо на си - не гибко. В ядре оси, особенно микроядре, большинство функций давно "стандартизованны", и принимаются де-факто. Если отвлечься от ядра, то и в "верхних слоях" прослеживается определённая закономерность. Спрятав эти "закономерности" в языке, можно писать программы, ориентированные на логику работы всей системы: и ядра, и сервисов, и приложений. А разделение логики работы не по функционалу, а по реализации порождает кучу вредных "интерфейсов" между железом и конечным пользователем системы. И начинают появляться всякие микро- экзо- нано- ненано-. Ибо всё раскидано, нестандартизованно и всё для всего представляет опасность. Долой стереотипы, господа..

Некоторое время назад сломался комп. пришлось менять мат. плату в процессором и памятью. Жесткий диск остался прежний вместе с установленными осями (дос,колибри,winXP,CentOS4) - когда пробовал загружаться на новом железе - все оси кроме WinXP заработали как раньше - хотя в принципе это было совершенно другое оборудование. Пришлось переустанавливать её через дополнительный диск - конечно я в это время думал о том что можно было написать ось так - что бы не было таких вот дел. В принципе когда надо выбирать между производительностью и чем-то ещё - в наше время это "что-ещё" важнее ,по моему... Главное много времени уделить... продумать архитектуру ос в целом - все интерфейсы без привязки к оборудованию.

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

Кооперативные системы уступают вытесняющим ТОЛЬКО по реактивности (по детерменированности времени отклика), что нужно только ОС жёсткого РВ. Во всём остальном они не уступают, а превосходят, например: простота, возможность реализации на уровне языка, производительность, лучшшее соответствие логике работы сложных систем которые, как известно, разбивают на "объекты", а не на потоки. Способ решения зависаний в обеих системах одинаковый. Просто нужно уметь её готовить..