OSDev

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

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

PS Мне погремуха Химик больше нравится.

Что касается конкуренции, тут я полностью согласен. Особенно между процессами. Особенно между пользователями. А вот с таймаутом микроскундным не согласен. В вытесняловке вытеснение по таймеру вещь обычная, а в кооперативке - ошибка, которую следовало бы исправить. Не знаю где здесь грань провести, но это очевидно не одно и то же. Жду, когда SII скажет, что всё дело в грамотно реализованном потоке.

З.Ы. Ок, я ближе к осени тоже химик;)

Опять же, и от вытесняющей и от кооперативной систем ждут определённой интерактивности. Справедливо требовать от потока/программы/компьютера реакции на внешние/внутренние события в установленном интервале времени. Иначе реакция может просто потерять свою актуальность. В ОСРВ порой важны считанные такты процессора от происшествия события к его обработке. В системах с графическим интерфейсом достаточно перерисовывать "окно" не чаще 25-30 в секунду. А обновление страницы в браузере может занимать несколько секунд. Если кооперативные потоки способны уложиться в заданный для них промежуток времени, то быть кооперативной многозадачности. В противном случае и система с вытесняющей многозадачностью, не укладывающаяся в установленные рамки не стоит ничего. А гладкость распределения процессорного времени зависит только от размеров наблюдателя:)

И напоследок: OSA - кооперативная многозадачная ОСРВ http://wiki.pic24.ru/doku.php/osa/ref/intro

А если надо немедленно обрабатывать события, время наступления которых непредсказуемо? В кооперативной системе придётся _постоянно_ опрашивать некую линию или ещё что, чтобы увидеть факт наступления события и перейти к его обработке. Ну а в нормальной вытесняющей многозадачной системе будет использоваться прерывание. В результате суммарная производительность системы с вытесняющей многозадачностью окажется значительно выше: у "кооператива" изрядная часть времени будет уходить на опрос. Добавьте к этому более низкую надёжность кооперативной системы как из-за сильных взаимосвязей между различными частями по сути одного потока (завис код в одном месте -- висит всё, поскольку зависший поток не передаёт управление другим), так и из-за большей сложности программирования таких кооперативных потоков, где программист сам должен учитывать всякие временные соотношения, чтобы вовремя отдавать управление другому потоку. В общем, годится кооперативная многозадачность только для специфических случаев.

Кстати говоря, вытесняющая задачность вовсе не предполагает непременного вытеснения по таймеру. Снятие потока с выполнения по истечении некоторого времени -- это квантование времени (time slicing) или разделение времени (time sharing). ОС с вытесняющей многозадачностью вовсе не обязательно имеет этот механизм, хотя обычно он присутствует. Например, и OS/360, и RSX-11 могли быть сгенерированы как с поддержкой разделения времени, так и без оного. Во втором случае некий поток снимался с выполнения только в том случае, если появлялся готовый к выполнению поток с более высоким приоритетом. В первом же случае квантование времени распространялось лишь на потоки, чьи приоритеты находились в некоторых заранее определённых границах. Если у потока приоритет был выше, чем у группы квантования времени, он находился на процессоре до тех пор, пока сам его не покидал (перейдя в ожидание или завершившись) либо пока не появлялся ещё более приоритетный поток. Поток с более низким приоритетом, чем у группы квантования, мог выполняться только тогда, когда не было ни одного более приоритетного потока вообще, включая группу квантования. Ну а в этой группе потокам выделялось время в зависимости от настроек параметров системы и их приоритетов. В целом получалось наиболее удобное и удачное распределение времени: и критичные к времени выполнения потоки обслуживались эффективно, и никого из основной массы не обижали, и низкоприоритетная работа не мешала выполнению более важной.

Прерывания должны работать с вытеснением точно так же как в ДОСе, на то они и прерывания. В такой конфигурации система может работать нормально. Я где-то слышал, что кто-то сделал конфигурацию ядра Linux без таймерного квантования - и вроде работало.

В кооперативке установление факта наступления некоего события вовсе не означает активный опрос. Для этого есть обработчики прерываний. Да, и они таки вытесняют! Но не отдельный поток, а всю потоковую среду (на все потоки один tss*). Вытесняют, вешают флаг события или отправляют сообщение вторичным (кооперативным) обработчикам, и возвращают управление прерванной системе. Когда прерванный во время исполнения поток отдаст управление диспетчеру-планировщику, тот в нормальном порядке проверит очередь событий (не произошло ли прерывание?), и выберет из списка новую задачу в установленном порядке. Я встречал такие системы, в которых даже не требуется опрос очереди событий. Просто первичный обработчик сразу выполняет диспетчеризацию вторичного, переводя его из состояния "ждущий" в состояние "готов".
SII, так же не стоит путать диспетчеризацию и планирование. Диспетчер - это мужик, переводящий поток в различные состояния в установленном порядке. В вытесняющей мн. диспетчер "резкий", а в кооперативке "отложенный". Всё зависит от нужного времени реакции. А планирование - это политика распределения проц.времени между потоками. В кооперативке она может быть и раунд-робин, и с приоритетами, и справедливое планирование (когда маленьких не обижают). В общем, всё как и в "нормальной" системе.
Вопрос: с какой это стати кооперативные системы менее стабильны систем с вытеснением? Что касается применения: везде, где требуется высокая производительность, не требующая микросекундных откликов. Например, "проблема 10000 соединений" у высокопроизводительных серверных систем.

«Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы» Алан Кокс

Касаетельно низкой надёжности кооперативных систем.
Кооперативную систему легко вывести из зависшего состояния по таймауту. pavia об этом тоже говорил выше. Таймаут - признак того, что текущий поток "повис". А как определить, что повис поток в вытесняющей системе? - По таймауту! По таймауту ответа на запрос. Т.е. в вытесняющей системе нужно устанавливать таймауты на ответы на запрос. В микроядре L4 в каждом отправляемом сообщении кодируется время, в течении которого сообщение должно быть прочитано. Для каждого потока ядро поддерживает список таймеров на каждое отправленное сообщение. Если сообщение не дошло в срок - значит получатель "висит". В кооперативке нужно поддерживать один таймер на все потоки. Не отдал управление диспетчеру в течении 1 мс - значит висишь. И где проще? К тому же кооперативка вовсе не предусматривает "тесную" связь потоков. Потоки так же могут быть разнесены по разным адресным пространствам.
Главное достоинство кооперативной многозадачности в том, что она может быть реализованна без механизмов ядра ОС. Многие языки поддерживают активные объекты или сопрограммы на уровне синтаксиса или библиотек функций. За стабильность работы кооперативки будет (и должен) отвечать язык. Главный недостаток - большой разброс времени на реакцию на событие, что неприемлемо для ОС жесткого реального времени. Как часто приходится писать жескткие ОСРВ?:)

Ага, чуть превысил отведенный лимит и ты труп. А если не убивать, а просто забирать управление, то это по сути тайм слайсинг без вытеснения, который давным давно доказал свою непригодность для интерактивных систем. Кстати, у меня и такое есть (идея родилась год или два назад в процессе беседы с Химиком). Этот приоритетный класс тоже называется real time, только предназначен он в первую очередь для приложений. Суть в том, что каждое значение приоритета для данного класса связано с вполне определенным временным промежутком, в течение которого поток может выполняться непрерывно (естественно, если нет потоков с более высоким приоритетным классом - у меня реализована полноценная вытесняющая многозадачность на основе приоритетов), и который не зависит от величины кванта планировщика.

Расскажи, как твоя полноценная многозадачная система узнаёт о зависших потоках?

Ху из "таймслайсинг без вытеснения"? 95% кода современных интерактивных систем (от GUI до компьютерных игр) представляют из себя кооперативную организацию динамических объектов, управляемых событиями (event driven).

Отличная штука, должно быть?! ;-)