Что такое функционирование в «Реальном масштабе времени»

Разделение нитями с разными приоритетами общих ресурсов 
может привести к классической проблеме инверсии приоритетов. 
Чтобы избежать этого, ОС РВ должна допускать "наследование" 
приоритета, подталкивая нить с низшим приоритетом. 
Наследование приоритета означает, что блокирующая нить 
наследует приоритет нити, которую она блокирует (конечно, только 
если последняя обладает более высоким приоритетом). 
5. 
Временные характеристики ОС должны быть 
предсказуемы и известны. 
Разработчик СРВ должен знать, сколько времени 
затрачивается на ту или иную системную работу. Кроме того, 
должны быть известны уровни системных прерываний и уровни 
IRQ 
(линий запросов прерываний) драйверов устройств, 
максимальное время, которое они затрачивают, и т.п. 
Несмотря на то что сегодня Windows NT не отвечает в полной 
мере требованиям, предъявляемым к операционной системе 
реального времени, давление рынка привело к появлению 
коммерческих решений, расширяющих NT возможностями 
обработки в реальном времени.
Удовлетворяет ли Windows NT требованиям, предъявляемым 
к ОС РВ? 
Очевидно, что NT – многонитевая ОС, она позволяет 
вытеснение и тем самым удовлетворяет требованию 1. 
В Windows NT имеются два класса приоритетов: класс 
реального времени и динамический класс. Процессы в классе 
реального времени имеют фиксированный приоритет, менять 
который может лишь само приложение, тогда как приоритет 
процессов динамического класса может меняться диспетчером. 
Процесс имеет базовый уровень приоритета. Нить в процессе может 
иметь приоритет в диапазоне плюс/минус 2 около базового уровня 
или один из двух крайних уровней класса (16 или 31 для реального 

---

56 
времени). Например, нить в процессе с базовым уровнем 24 может 
иметь приоритет 16, 22 – 26, 31. Очевидно, что гарантировать 
предсказуемость системы можно только при использовании 
процессов первого класса. 
Казалось бы, второе требование также удовлетворено. Но 
малое число возможных уровней препятствует реализации СРВ на 
базе NT. Большинство современных ОС РВ позволяет иметь, по 
крайней мере, 256 различных уровней. Чем больше имеется 
уровней, тем более предсказуемо поведение системы. В Windows NT 
имеется только 7 различных уровней для нити в данном процессе. 
В результате многие нити будут выполняться с одинаковыми 
приоритетами и, как следствие, предсказуемость поведения 
системы будет посредственной. Более того, общее число уровней 
для всех процессов класса только 16 и положение не спасает даже 
замена нитей процессами, не говоря уже о том, что переключение 
контекста для процессов снижает производительность. 
В ОС РВ вызовы системы синхронизации (семафоры или 
критические секции) должны уметь управлять наследованием 
приоритетов. В Windows NT это невозможно, поэтому требование 4 
не удовлетворяется. 
Еще одна проблема обусловлена реализацией некоторых 
вызовов системы GUI. Они обрабатываются синхронно 
(вызывающая нить приостанавливается, пока не завершится 
системный вызов) процессом, выполняемым с более низким 
приоритетом (динамического класса). В результате нить может 
помешать нити с более высоким приоритетом – возникает инверсия 
приоритета. 
Таким образом, малое число приоритетов и невозможность 
решить проблему инверсии делают Windows NT пригодной только 
для очень простых СРВ. 
Предсказуемость системных вызовов Win32 API. 
Для тестирования системных вызовов был написан процесс 
(принадлежащий классу реального времени), содержащий вызовы 
системы синхронизации нитей, и измерялось время, затраченное на 

---

57 
каждый вызов. Максимальное значение на вызове mutex достигает 
670 мкс при среднем времени 35 мкс. Это произошло потому, что 
во время работы теста происходили обращения к диску и по сети. 
Если компьютер искусственно загрузить обращениями к диску и 
сетевой обработкой, то задержки возрастают до нескольких 
миллисекунд. Win32 API очень богат, но не предназначен для 
реального времени. Например, запросы mutex обрабатываются в 
порядке поступления, а не в порядке приоритетов, что снижает 
предсказуемость. Для синхронизации нитей в одном процессе 
критические секции следует предпочесть всем другим способам 
(этот вызов затрачивает всего несколько мкс по сравнению с 35 мкс 
на вызов mutex). 
Несмотря на все достоинства API, ядро и менеджер 
ввода/вывода Windows NT недостаточно приспособлены к 
обработке событий реального времени на уровне приложений.