Привет коллеги.
Нет, я не гуру в PMODE и даже не :)))
Но вот интересные задачи меня как то необходят стороной :).

Я знаю, сколько тут народу есть пишущих ОС. Поэтому читатели найдутся. Вот решил пофантазировать, как должен работать высокооптимальный менеджер задач + ядро.

==========================================================
-= Предположения =-
1. Распределение времени будет осуществляться по таймеру.
2. Архитектура системы -- схожая с реализацией задач в INTEL
3. Ядро предоставляет API для управление задачами
Оно позваляет:
1. Активировать задачу
2. Остановить её
3. Убить.
4. Создать
==========================================================

-= Теория =-

Задачи (потоки) имеют приоритет (пусть как у Win32 31 значение)
Задача имеет 2 состояния:
1. Работает
2. Ожидает
3. Только создана (этот бит общий со след списком)
4. Убита (нет задачи)

Задача имеет несколько видов статутса:
1. Естественный статус
2. Голодание (время)
3. Избыток (время)
4. Только создана (этот бит обжий с предыдущим списком)

Ядру всегда известен ENV-статус задачи, который содержит информацию о:
1. Кто ждёт задачу.
2. Что ждёт задача
3. ---

Ядро распологает подсистемой событий Ядра (например как в Win32 События, мютексы.. и так далее).

ПодСистема событий рассматривается точно так же как IRQ.

=========================================================
-= Структура хранения =-

Мы будем говорить, что все данные задачи уложены в одномерный масив, где индекс -- ID задачи
Я не знаю, что это за массив и не хочу знать.
Это может быть массив указателей, массив структур.. и так далее

Но, я предложу интересное представление этого массива, для эффективного управления задачами.

Дело в том, что в этом массиве положение элемента (начало / конец) имеет значение приоритета задачи.
Это значит, что первые элементы массива -- это задачи с высшим приоритетом, а более последние элементы --
это задачи с низшим...

Мы назовём этот массив tasks

Кроме того, система содержит массив priority. Этот массив содержит ЗНАЧЕНИЯ ИНДЕКСов в массиве
tasks, с которого начинается данный приоритет.
Так например, если приоритетов у нас 31, то элементов в этом массиве 31.

По двум массивам менеджер может легко определить какой приоритет имеет задача.
Для этого, ему нужно перебрать массив prioruty, и посмотреть в какой зоне приоритетов
находится сейчас задача.

(Но это же долго!!!!! Скажите вы. Но пока рано. :))

В массиве priority всё расположим точно так же:
то есть первые элементы -- высшие приоритеты
а последние элементы -- низшие.



Кроме того, у нас будут вспомогательные переменные.
1. Переменная nest_task - хранит ID следующей задачи на очереди
2. Переменная hsleep_task - хранит ID верхней гнаницы спящих задач
(это имеется ввиду, что задачи с высшим приоритетом обычно спят...
поэтому и введена такая переменная)

Например массив tasks
- спит
= в очереди
* исполняется

[------------======*===-===-==]
hsleep_task-^       ^- nest_task

3. ctask_level Текущий уровень приоритета выполняющейся задачи

4. cnexttask_level Уровень приоритета следующей задачи

5. max_active_priority Максимальной Уровень приоритета задачи, которая ждёт очереди.

==========================================================
-= Алгоритм работы менеджера =-

1. Произошёл тик таймера
2. Проверить, max_active_priority > cnexttask_level
2.1 Если да, то начать выполнять не nest_task, а задачу, которая активировалась на том уровне
2.2 Иначе
3. Выполнить эту задачу, если только она не ожидает и установить значения переменных.

Остальные переменные используются для ускорения алгоритма.
Так например, если max_active_priority > cnexttask_level
то алгоритм, может сразу посмотреть где находится hsleep_task, и не анализировать ту часть массива
Поскольку спящие задачи должны иметь как правило высокие приоритеты..
то такой подход является верным.

* hsleep_task не изменяется ядром, когда происходит вызов задачи по событию.!!!

Now you can start to write this os. :)

kID
Погоди, я только начал топик :)))