Диспетчеризация и реальный мир
До настоящего момента мы обсуждали дисциплины диспетчеризации и состояния потоков, но практически ничего не сказали относительно того, почему и когда происходит собственно перепланирование. Существует распространенное заблуждение, что перепланирование «просто случается», безо всяких реальных причин. И в общем-то, для проектирования это довольно полезная абстракция! Однако, очень важно понимать, почему происходит перепланирование. Вспомним рисунок «Схема алгоритма диспетчеризации» (в разделе «Роль ядра»).
Перепланирование может иметь только три причины:
• аппаратное прерывание;
• системный вызов;
• сбой (исключение).
Перепланирование по аппаратному прерыванию
Перепланирование из-за аппаратного прерывания можно разделить на две категории:
• по прерыванию от таймеров;
• по прерыванию от других аппаратных средств.
Часы реального времени генерируют периодические прерывания для ядра, организуя перепланирование во времени.
Например, если вы производите вызов sleep(10), часы реального времени сгенерируют некоторое число прерываний; по каждому прерыванию ядро увеличивает значение системных часов. Когда системные часы покажут, что 10 секунд истекли, ядро перепланирует ваш поток, переведя его в состояние готовности (READY). (Мы рассмотрим этот вопрос более подробно в главе «Часы, таймеры и периодические уведомления»).
Другие потоки могут ожидать аппаратные прерывания от внешних устройств, таких как последовательный порт, жесткий диск или аудио платы. В этом случае они блокируются в ядре, ожидающем аппаратное прерывание. Поток будет переупорядочен ядром только после того, как ядро сгенерирует «событие».
Перепланирование по системным вызовам
Если поток делает системный вызов, перепланирование выполняется немедленно и может рассматриваться как асинхронное в отношении прерываний таймера и других прерываний.
Например, выше мы приводили пример вызова функции sleep(10). Это библиотечная функция языка Си, в конечном счете она транслируется в системный вызов. В тот же самый момент ядро приняло решение о перепланировании, чтобы удалить ваш поток из очереди готовности по соответствующему приоритету и поставить на выполнение другой поток, находящийся в состоянии готовности (READY).
Системных вызов, вызывающи процесс обязательного перепланирования, очень много. Большинство их них достаточно очевидны. Перечислим некоторые из них:
• функции таймера (например, sleep());
• функции обмена сообщениями (например, MsgSendv());
• примитивы работы с потоками (например, pthread_cancel() или pthread_join()).
Перепланирование по исключительным ситуациям
Последняя из вышеперечисленных причин перепланирования — это сбой процессора (CPU fault), который является исключительной ситуацией (exception) — чем-то средним между аппаратным прерыванием и системным вызовом. Исключительные ситуации асинхронны в отношении ядра (подобно прерыванию), но синхронны с вызывающими их пользовательскими программами (подобно вызову ядра — например, такая исключительная ситуация как деление на ноль). Все рассуждения, относящиеся к перепланированию по прерываниям от аппаратных средств и по системным вызовам, относятся и к исключительным ситуациям тоже.
Операционная система QNX/Neutrino предлагает богатые возможности диспетчеризации потоков — минимальных диспетчеризуемых единиц. Процесс в QNX/Neutrino определяется как минимальная единица, способная обладать ресурсами (например, областями памяти), и может содержать один или более потоков.
С потоками можно применять любые из следующих методов синхронизации:
• мутексы (mutexes) — владеть мутексом в заданный момент времени может только один поток;
• семафоры (semaphores) — владеть семафором позволяется некоторому фиксированному числу потоков;
• ждущие блокировки (sleepons) — позволяют нескольким потокам блокироваться на нескольких объектах, динамически назначая блокированным потокам соответствующие условные переменные;
• условные переменные (condvars) — подобны ждущим блокировкам, за исключением того, что за распределение условных переменных отвечает программист;
• присоединение (joining) — обеспечивает синхронизацию потока по отношению к завершению другого потока;
• барьеры (barriers) — позволяют потокам ждать, пока определенное число потоков не встретится в определенной точке.
Отметим, что мутексы, семафоры и условные переменные могут использоваться между потоками как в том же самом, так и в разных процессах, ждущие же блокировки могут применяться только между потоками одного и того же процесса (потому что системный мутекс библиотеки ждущих блокировок «скрыт» в адресном пространстве процесса).
Наряду с синхронизацией, потоки можно диспетчеризовать (используя приоритеты и различные дисциплины диспетчеризации), и они автоматически могут выполняться как в однопроцессорном блоке, так и в системе с архитектурой SMP.
Всякий раз, когда мы говорим о «создании процесса» (обычно как о средстве переноса однопоточного кода), мы действительно создаем адресное пространство с одним работающим в нем потоком — этот поток стартует по вызову функции main() или функций atfork() или vfork(), в зависимости от реализации.
Введение в обмен сообщениями
В данной главе мы рассмотрим наиболее характерную отличительную особенность QNX/Neutrino — механизм обмена сообщениями. Обмен сообщениями в QNX/Neutrino — ключевой механизм, глубоко интегрированный с микроядерной архитектурой этой операционной системы и обеспечивающий ей ее модульность.
Микроядро и обмен сообщениями
Одним из основных преимуществ QNX/Neutrino является то, что данная операционная система является масштабируемой. Под «масштабируемостью» здесь подразумевается, что данная система может быть адаптирована к работе как в крошечных встраиваемых системах с ограниченными ресурсами, так и в больших сетях симметричных многопроцессорных систем (SMP), т.е. систем, ресурсы которых практически неограничены.
В операционной системе QNX/Neutrino такой уровень универсальности достигается разнесением различных сервисов по отдельным модулям. Таким образом, вы имеете возможность включить в конечную систему только те компоненты, которые вам действительно необходимы. Используя многопоточность, вы также упрощаете своему проекту «масштабируемость вверх» для использования его в SMP-системах (в данной главе мы рассмотрим еще ряд полезных применений для потоков, которые мы не обсуждали ранее).
Эта концепция была изначально заложена во все ОС семейства QNX и соблюдается по сей день. Основным принципом построения этих систем является микроядерная архитектура, когда модули, которые в традиционной операционной системе были бы включены в состав ядра, рассматриваются как необязательные компоненты.
Модульная архитектура QNX/Neutrino.
Какие из модулей применить в проекте — это уже решать проектировщику, то есть вам. В вашем проекте необходима файловая система? Если да, включите ее в проект. Если нет — можете не включать. Вам необходим драйвер последовательного порта? Каков бы ни был ваш ответ, он не повлияет на предыдущее решение касательно файловой системы, равно как и не будет от него зависеть.
В процессе работы системы вы также имеете возможность изменять ее состав. Вы можете динамически удалять любые компоненты из работающей системы или добавлять их, в любой произвольный момент времени. Вы спросите, существуют ли какие-либо ограничения относительно «драйверов»? Нет, не существуют — драйвер в QNX/Neutrino является стандартной пользовательской программой, которая разве что выполняет определенные действия с оборудованием. Мы обсудим, как писать такие программы, в главе «Администраторы ресурсов».
Ключом к реализации всего этого является обмен сообщениями. Вместо встраивания модулей ОС непосредственно в ядро и обеспечения между ними некоего «специального» взаимодействия, в QNX/Neutrino модули общаются друг с другом посредством обмена сообщениями. Ядро в основном отвечает только за служебные функции на уровне потоков (например, за диспетчеризацию потоков). На самом деле, обмен сообщениями используется не только для трюков с динамической инсталляцией и деинсталляцией компонентов — на нем основаны большинство всех остальных служебных функций (например, распределение памяти выполняется путем отправки специализированного сообщения администратору процессов). Впрочем, конечно, некоторые сервисы реализуются непосредственно через системные вызовы.
