OSDev

Согласен, многабукв. Попробую в нескольких словах.
Главная штука в системе - список объектов. Содержит записи следующего вида:
Имя объекта, Ожидаемое событие.
Планировщик переключает объекты, не ожидающие событий (Ожидаемое событие = 0).
Объекты могут посылать/ожидать события (Event(), Wait()).
Wait(n) - записывает в поле "ожидаемое событие" число n.
Event(n) - пробегает по списку объектов, ищет все числа n, и заменяет их на 0.

Пример (двухуровневая обработка прерываний):
Объект А вызывает функцию Wait(123). В его поле "ожидаемое событие" записывается "123". Теперь планировщик при встрече будет игнорировать этот объект.
Происходит прерывание. Первичный обработчик вызывает Event(123). Эта функция пробегает по списку, находит А, и сбрасывает 123 в 0. Всё! Теперь А снова в списке планирования.

В общем-то логично, наверно это будет работать.
Побольше систем, хороших и разных! :-)

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

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

В кооперативке переключения происходят без сохранения контекста и без участия таймера. Поэтому таймер можно остановить без нарушения работоспособности. Может быть и небольшая экономия энергии, но всё-таки. Представь, что компьютер управляет звездолётом, который питается от тусклого света звёзд :-)

..Химик опередил.

Вытеснение - умение системы "снять с процессора" текущую задачу, и заменить её на другую, по своему усмотрению. Сохранение контекста и механизмы синхронизации - просто детали, необходимые для корректной работы системы. И неважно по какой причине происходит вытеснение - по прерыванию от таймера или любому другому. Вытесняющая система именно меняет задачи в реальном времени, а кооперативная просто "запоминает", что при очередном планировании следует принять в расчёт новое входное событие.
Для вытеснения под каждую задачу требуется свой TSS, а это добрая сотня байт (на каждую задачу). В кооперативке нужно знать только точку входа в объект (1/2/4/8 байт на объект). Именно поэтому кооперативка используется там, где нужно 1000-100000 потоков. Иначе просто нереальный расход памяти, и столь же нереальный расход процессорного времени на определение/переопределение структур в ядре, связанных с потоками. А задача с дэдлоками (взаимными блокировками) становится похожа на уравнение с миллионом неизвестных. А в кооперативке дэдлоков просто нет.. Получается, что вытесняющая многозадачность хороша до тех пор, пока потокам не требуется часто взаимодействовать и их небольшое число. Т.е. для специфических задач. ;-)

Вытесняющую можно реализовать программно - без TSS. Ну и технически красиво когда всем задачам процессорное время поровну. К тому же программы для такой ос (вытесн.) могут ничего и не знать о том что ос многозадачная.

Сейчас задумался (а утром на работу:) над вопросом пространства имён объектов. Ведь если система предусматривает работу 100(0).000 потоков (объектов), то не исключено совпадение имён. А поиск нужного объекта в списке будет занимать ооочень неопределённое время (от микросекунды до получаса:). Думаю, здесь резонно поступить, как когда-то поступили в Unix'е с файлами - разделить пространства имён по рабочим группам. Т.е. структуру списка объектов представить иерархически, в виде дерева или снежинки, как файловую систему. Сразу сокращается количество возможных имён, и представляется более удобная для пользователя область видимости объектов. Например: есть программа. Она определяет пространство имён задач. Каждая задача содержит потоки. Уже другая область. Каждый поток тоже может описывать свои имена. Т.е. имена в разных областях видимости могут совпадать. Если и дальше проводить аналогии с файловой системой, то объекты можно представить в виде файлов. У каждой группы объектов есть главный, централизующий объект, выполняющий их планирование, распределяющий ресурсы, осуществляющий связь с объектами из других групп - это папка. Есть корневой каталог, содержащий папки. Каждая папка может тоже содержать свои папки, и т.д.
Можно провести аналогии со снежинкой или деревом, которые так популярны в базах данных и всяких там системах синтаксического разбора. Централизующие объекты - узлы/листья. От них расходятся лучи/ветви.
А если представить объект не просто как именованный участок кода, а поименованный набор всех используемых им ресурсов: процессора, оперативной память, других имён, функций импорта/экспорта и т.п. - то объект превращается в настоящий файл! А "древовидная" структура списка имён, при этом, отлично совпадает со структурой распределения памяти в системе. Значит центральные узлы в группах могут выполнять роль крохотных микроядер: распределять память, планировать исполнение объектов, перенаправлять сообщения далее по ветке... В L4 память организованна именно так: менеджер памяти Sigma0 экспортирует память процессам, те распределяют её между потоками и т.д.
Не знаю, возможно-ли здесь даже отказаться от страничной памяти, представленной в виде кучи, в пользу некой "файловой системы". Чего-то, наподобие RAM-диска...
Наверное вопрос данной системы лучше обсуждать в отдельной теме, ибо с темой "производительности многопоточных сред" он уже связан слабо. Короче, предлагаю всем ОсДевом пофантазировать в свободном ключе над крохотной экзотической системой из далёкой волшебной страны:) Кто за - поднимите руку.. :)

Хорошо жить в свободной стране! Хочешь - вытесняешь, не хочешь - не вытесняешь... ;-)

http://www.mobile-review.com/articles/2011/android-multitask.shtml материал про многозадачность в андроид

В случае запуска приложений дос в ос Windows NT,XP - приложения эти работают не зная что они "многозадачные".