Отправляет email-рассылки с помощью сервиса Sendsay
  Все выпуски  

Разработка операционных систем - для начинающих и не только!


Информационный Канал Subscribe.Ru

Разработка операционных систем

Выпуск 24 от 2004-02-09

Сегодня в номере:

Intro

А не спеши ты нас хоронить,
А у нас еще здесь дела

Из песни

Простите, одна тема из форума навеяла... Итак,
Добрый день!
В сегодняшнем выпуске, уважаемые подписчики, мы уже в который раз продолжаем разговор о реализации многозадачности на процессорах архитектуры IA-32. Старенькая, конечно, архитектура, в следующем году ей уж 20 лет будет, но поскольку у большинства из вас, да и у меня тоже, процессор железного друга сработан именно по ней, мы продолжаем в ней копаться :) Благо суть - она и в Африке на альфе суть... А тем более на AMD64 :)

P.S. А нас уже больше 4000 :)

P.P.S. Объявление, уже сделанное в предыдущем выпуске, повторяю еще раз:)
Был создан дискуссионный лист "Разработка операционных систем - форум", в котором вы, уважаемые подписчики, можете задавать вопросы не только мне, но и друг другу, т.к. ваше письмо, отправленное по адресу
comp.soft.prog.osd-list@subscribe.ru получат все, кто подписан на этот лист. Для того, чтобы посылать письма на этот адрес, вам необходимо подписаться:

Рассылки Subscribe.Ru
Разработка операционных систем - форум.

Реализация многозадачности (часть 3)

Для освежения в памяти (три месяца все таки прошло :)) напомню, что в прошлом выпуске мы познакомились с общим принципом осуществления аппаратной многозадачности на IA-32. Состояние (контекст) выполняющейся задачи при переключении сохраняется в специальной структуре данных TSS, которая оформляется в GDT, как отдельный сегмент. Контекст же задачи, на которую осуществляется переключение, загружается из TSS этой задачи

Из этого следует, что организовывая многозадачность наиболее последовательным (хотя и неоптимальным) путем (имеется ввиду последовательным с документацией от Intel) нужно:

  • Создать для каждой задачи TSS и описать их в GDT
  • Загрузить селектор TSS для текущей задачи в регистр TR (командой LTR)
  • Каким-либо образом организовать диспетчер (по русски - переключатель) задач, т.е. устроить их поочередное выполнение, чтобы процессорное время выделялось каждой задаче

При практической реализации первых двух пунктов проблем обычно не возникает, благо работа это чисто механическая, а вот приступая к третьему пункту, разработчик ОС приступает к творчеству (читай: сталкивается с проблемами :)).

Исходя из собственного опыта, предполагаю, что предполагаемый (простите за каламбур) разработчик горит желанием поскорее сделать простейший переключатель задач, отбросив первоначально такие аргументы, как быстродействие, элегантность и им подобные. Поэтому вашему вниманию сперва предлагается Простейший Переключатель Задач, который минимум в 2 раза медленнее любого другого варианта, но является более предпочтительным в плане fool-proof, в том смысле, что ошибок при реализации его вы допустите меньше, а значит и отлаживать будет легче. В дальнейшем же, уловив общую идею, вы без труда реализуете и гораздо более сложные диспетчеры.

Переключение задач мы будем производить циклически (round-robin), по прерыванию таймера. Прерывание таймера для переключения задач вообще - наиважнейшая штука. Алгоритмы диспетчеров любой сложности используют именно его для контроля процессорного времени отведенного каждой задаче, а значит и мы без него не обойдемся.

Дескриптор в IDT для прерывания таймера мы оформим как шлюз задачи. Теперь, наконец-то, спустя 17 выпусков и восемь с половиной месяцев, пришло время рассказать о нем (надеюсь вы уже сами, сгорая от нетерпения, слазили в документацию и узнали, что это такое? :)).
Если дескриптор некого прерывания описывает шлюз задачи, то при возникновении этого прерывания, процессор переключает текущую задачу на ту, на селектор TSS которой указывает этот дескриптор. Т.е. процессор находит нужную TSS следующим образом:

Дескриптор Прерывания -> Номер Селектора -> Селектор в GDT -> Адрес TSS -> TSS 
Далее все происходит обычным при аппаратном переключении задач образом - контекст текущей задачи сохраняется в текущей TSS (селектор которой в регистре TR), из найденной TSS извлекается контекст новой задачи, в том числе и CS:EIP и процессор продолжает обычное выполнение.

Т.е., фактически, обработчик прерывания выполняется как отдельная задача.

Для нашего простейшего переключателя мы как раз и создадим обработчик прерывания таймера, как отдельную задачу. Зачем? Сейчас увидите :)

В хорошо знакомом нам регистре флагов EFLAGS существует флажок NT aka Nested Task, что в максимально отражающем исходный смысл переводе звучит как "Вложенная задача". Если этот флаг установлен, то команда IRET (возврат из прерывания) инициирует переключение задачи на ту, селектор TSS которой указан в поле backlink TSS текущей задачи. При вызове же прерывания, дескриптор которого есть шлюз задачи, и соответствующем переключении контекста, как раз и устанавливается флаг NT.

Самые проницательные уже догадались, что обработчик прерывания таймера, который есть отдельная задача, будет у нас изменять свой backlink (backlink TSS'a своей задачи, если быть точным) на селектор той задачи, на которую нужно переключиться, благодаря чему и будет достигнута столь желанная нами многозадачность. Ура! :)

Небольшое оступление от темы выпуска. Не стоит сильно возмущаться отсутствием практических примеров, точнее отсутствием готового кода этих примеров в рассылке. На то есть такие причины:

  1. Успехов в разработке ОС достигнут в любом случае лишь те, кто способен написать код этих примеров самостоятельно, а не только скомпилировать готовый. Базовые же примеры, для "разгона", были уже даны в начальных выпусках рассылки.
  2. Большинство из описанных механизмов (да еще и кучу других) можно найти как в Tyros, так и множестве других свободно распространяемых ОС с открытыми исходниками.
Также спешу опровергнуть возникающие у некоторых из вас из-за отсутствия кода сомнения в алгоритмах, используемых в примерах. Все примеры, приведенные в рассылке были в свое время воплощены мною в коде, независимо от того приводится ли их код в рассылке или нет. Соответственно за работоспособность и правильность алгоритмов этих примеров я ручаюсь.

Те господа, которые тремя абзацами выше оказались самыми проницательными, уже наверняка поняли, что и в этом выпуске готового кода не будет :)

Продолжение следует...

На этом, уважаемые подписчики, я прощаюсь, и как всегда напоминаю, что:

lonesome AT lowlevel DOT ru - мой почтовый ящик, который с нетерпением ждет ваших писем в любое время дня и ночи
http://www.lowlevel.ru - Сайт. Наш сайт :)
http://www.lowlevel.ru/articles/ - Архив всех выпусков рассылки (кроме того, его можно найти здесь)

http://www.lowlevel.ru/cgi-bin/yabb/YaBB.cgi - Форум
Посмотреть 10 последних сообщений форума

http://sf.net/projects/tyros/ - Открытая операционная система Tyros/Neutronix, разрабатываемая по материалам нашей рассылки


Желаю удачи!
Lonesome


http://subscribe.ru/
E-mail: ask@subscribe.ru
Отписаться
Убрать рекламу

В избранное