OSDev

Это не очевидно, потому что и следующие версии Windows зависали не меньше. При этом ясно, что нет ни каких проблем снимать зависшую программу по таймеру. Возможно, там просто не было сторожевого таймера, или причина зависаний была другая, одному Биллу Гейтсу известная.

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

К тому же: пока в кооперативке идёт реанимация упавшего, все остольные "ждут". Т.е. не пишутся диски, не отправляются пакеты в сеть и т.д. Реанемировали - система продолжила работу. В вытесняловке: пока реанемируется упавший, система нормально работает. Пишутся диски, отправляются пакеты в сеть.. Но если хоть один из потоком пошлёт сообщение реанемируемому - держи дэдлок! Взаимная блокировка! Допрыгались?! Ресет..

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

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

Возможно теперь никаких новых идей и ненужно - изучаем старые оси - пишем с учётом всех ... Просто красиво пишем ось - я бы сказал калиграфически. А более интересные высокоуровневые функции можно реализовать поверх ("обычных") осей..? Может в рамках osdev.ru разработать общий интерфейс... (Хотя ,конечно интерфейс чего? - трудно обсуждать то - чего в принципе ещё никто не делал...)

Слава богу, лёд тронулся с места. А то я думал так и будем обработчики обсуждать всё время..

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

Нижний уровень - уровень обработчиков прерываний и исключений. Это те объекты системы, которые получают управление внезапно, т.е. асинхронно, по отношению к работе системы. Отдельно об обработчиках:
1. Обработчики прерываний. Их главная задача - избавить верхний уровень от активного опроса при работе с устройствами в/в, при этом представляя асинхронные события в синхронной форме. Два способа сделать это - "буферизировать" события, добавляя их в очередь событий, либо сразу выполнять диспетчеризацию "ожидающих", не откладывая на потом. Лично мне больше нравится второй вариант. Все обработчики прерываний при этом - маленькие однообразные функции, но с разным "кодом" прерывания.
2. Обработчики исключений. Те ситуации, которые требуют неотложной реакции системы обрабатываются ими. Это может быть и ошибка деления на ноль, и страничное исключение и т.д. Да хоть нажатие правой кнопки мыши, если это так критично. Обработка исключений может быть и вложенной, по всем канонам и правилам. Хотя я не вижу в этом особого смысла. Трудно представить ситуацию, когда, например, обработчик страничного исключения вызвал бы ошибку деления на ноль, или наоборот. Естественно, обработчики исключений более толстые, чем "братья по уровню", да и функции у них по-разнообразней.

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

Возможные функции здесь:
Message(Destination, &Msg) - отправить сообщение.
WaitMessage(Source*, &Msg) - ждать сообщение.
Event() - "создать" событие.
WaitEvent(Source) - ждать событие.
Sleep() - пропустить "ход".

Звёздочкой пометил источник, в случае не указания которого является возвращаемым аргументом (что вероятнее всего).

Или более краткий вариант в духе L4:
Msg(PID, &Msg, operation_type) - в зависимости от выбранного типа операции, отправляет/принимает сообщения/события. Передаваемые и принимаемые аргументы определяются типом операции, как и вызов команды Sleep().

Текст не осилил, да и не озабочен пока этим делом. Да вот нашёл одно потенциальное достоинство кооперативки - это минимизация процессорного пробуждения ввиду отсутствия механизма вытеснения, и соответственно экономия энергии, длительность работы ноутбуков / разных мобильных устройств. Это навеяло статьёй про энергосбережение
http://www.opennet.ru/tips/2657_power_d ... rtop.shtml
Конечно это не определяющее достоинство, но довольно жирный плюсик. Хотя опять же, не для ПК.

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