OSDev

Почему подавляющее большинство разработчиков придерживается следующей модели?

Загрузка исполнимого кода ОС и передача управления на него => Инициализация =>
Добавление системных задач в очередь => while (!shutdown) { Task* task = dequeue_task(); task->execute(); }

** Состояние очереди может изменяться обработчиками прерываний.

P.S. Понимаю, что однозначного ответа на вопрос нет. Интересует мнение.

Задача ОС - выполнять задачи пользователя, и обслуживать периферийные устройства (прерывания).

Думаю это от того что компьютер это ЭВМ
Электронно вычислительная машина. И ей нужно что-то вычислять считать. А таких вот задач вычислительных много и они долгие. А программы в частности ОС пишутся как раз для вычислительных машин.

Да не вопрос У нас есть вычислительная машина, мы ее загружаем решением имеющихся задач.

Но почему "загрузчик" этих задач почти всегда реализуется так, как описано в первом сообщении? Другими словами, почему именно бесконечный цикл с выборкой задач из очереди?

Почем бесконечный цикл? Так задач бесконечное число.
Почему очередь? Так не обязательно. Просто это самый простой способ планирования.

В смысле бесконечно много? Бесконечный цикл, чтобы ОС могла выполнять свою основную функцию постоянно, пока работает. Кстати, цикла в явном виде может и не быть. Например, у меня используется просто переключение на следующую в очереди выполнения задачу (или на текущую в другой очереди выполнения), а т.к. очереди выполнения имеют кольцевую структуру, то и получается цикл.

Представьте, что вместо ... - hlt, а любая работа системного уровня активируется обработчиками прерываний. Как мне кажется, такую модель вполне можно реализовать. Кто-то из участников форума ее вообще рассматривал?

hlt, естественно, присутствует в специальных низкоприоритетных потоках ядра.

Да, только как средство разгрузки проца.

P.S. Не знаю, как еще говорить о лесе, если все видят только деревья

Тут пытались обсуждалась функциональную ОС ( ОС на ЛИСП). Все согласились что это утопия.
Если бы всё было так просто то бы ОС не потребовалось, а достаточно было бы сделать контролёр на основе теории автоматов. Без всяких софт процессоров.
Но в реальности требуется выполнять несколько задач одновременно. А так как входные параметры случайные. Сегодня жёсткий диск считал файл за 1 мс завтра попала соринка за 2 мс.
Или метастабильность из-за который раз в 1 час обязательно да бывает ошибка. Или из-за грозы прошла импульсная помеха и в TCP соединение потерялся пакет ACK и сеть повисла на 1 минуту.
Вот и приходиться планировать рациональное использование процессора с учётом неравномерного поступления входных команд(событий, сигналов, прерываний) и того что как правило требуется одновременно выполнять несколько команд.
Как рационально загрузить процессор что-бы он быстрее закончил работу? Вот и приходиться маневрировать пока одна задача ждёт порцию данных что-бы рассчитать контрольную сумму. Другая отправляет запрос, а третья записывает на жёсткий диск. При этом та которая пишет на жёсткий диск ещё должна рассчитать куда писать с учетом что четвёртая ведёт дефрагментацию которая внезапно начала исполняться на середине записи в файл.