Гордеев А.В. Операционные системы (2-е изд., 2004) (1186250), страница 76
Текст из файла (страница 76)
Микроядерные операционные системы в полной мере используют модель клиент-сервер.При поддержке монолитных операционных систем возникает ряд проблем, связанных с тем, что все компоненты макроядра работают в едином адресном пространстве. Во-первых, это опасность возникновения конфликта между различньми частями ядра, во-вторых, сложность подключения к ядру новых драйвереПреимущество микроядерной архитектуры перед макроядерной заключается в TOIV,что каждый компонент системы представляет собой самостоятельный процес ,запуск или остановка которого не отражается на работоспособности остальньпроцессов.требования к операционным системам реального времени293Микроядерные операционные системы нынче разрабатываются чаще монолитных.Однако следует заметить, что использование технологии клиент-сервер — это ещеН е гарантия того, что операционная система станет микроядерной. В качестве подтверждения этому можно привести пример с операционными системами классаWindows NT, которые построены на идеологии клиент-сервер, но которые тем неменее трудно назвать микроядерными.
Их «микроядро» имеет уже достаточно большой размер, приставка «микро» здесь вызывает улыбку. Хотя по своей архитектуре супервизорная часть этих систем без каких-либо условностей может быть отнесена к системам, построенным на базе модели клиент-сервер. Причем для последнихверсий операционных систем с общим названием NT (New Technology) еще болеезаметным является отход от микроядерной архитектуры, но сохранение принципаклиент-сервер во взаимодействиях между модулями управляющей (супервизорной) части. Для того чтобы согласиться с таким высказыванием, достаточно сравнить операционную систему QNX и операционные системы Windows NT/2000/ХР.Требования к операционным системамреального времениКак известно, система реального времени (СРВ) должна давать отклик на любыенепредсказуемые внешние воздействия в течение предсказуемого интервала времени.
Для этого должны выполняться следующие требования.•Ограничение времени отклика. После наступления события реакция на него гарантированно должна последовать до предустановленного крайнего срока. Отсутствие такого ограничения рассматривается как серьезный недостаток программного обеспечения.•Одновременность обработки.
Даже если наступает более одного события одновременно, все временные ограничения для всех событий должны быть выдержаны. Это означает, что системе реального времени должен быть присущ параллелизм, что достигается использованием нескольких процессоров и/илимногозадачного подхода.Примерами систем реального времени являются системы управления атомнымиэлектростанциями или какими-нибудь технологическими процессами, системымедицинского мониторинга, системы управления вооружением, системы космической навигации, системы разведки, системы управления лабораторными экспериментами, системы управления автомобильными двигателями, робототехника,телеметрические системы управления, системы антиблокировки тормозов, системы сигнализации — список в принципе бесконечен.Иногда можно услышать из разговоров специалистов, что различают системы «мягкого» и «жесткого» реального времени.
Различие между жесткой и мягкой СРВзависит от требований к системе — система считается жесткой, если «нарушениевРеменных ограничений недопустимо», и мягкой, если «нарушение временных0граничений нежелательно». В недалеком прошлом велось множество дискуссий0точном смысле терминов «жесткая» и «мягкая» СРВ. Можно даже показать, что294Глава 9. Архитектура операционных системмягкая СРВ не является СРВ вовсе, ибо основное требование о соблюдении временных ограничений не выполнено.
В действительности термин СРВ часто неправомерно применяют по отношению к быстрым системам.Часто путают понятия СРВ и ОСРВ (операционная система реального времени)а также неправильно используют атрибуты «мягкая» и «жесткая», когда говорятчто та или иная ОСРВ мягкая или жесткая. Нет мягких или жестких операционных систем реального времени. ОСРВ может только служить основой для построения мягкой или жесткой СРВ.
Сама по себе ОСРВ не препятствует тому, что вашаСРВ будет мягкой. Например, пусть вы решили создать СРВ, которая должна работать через Ethernet по протоколу TCP/IP. Такая система не может быть жесткой СРВ, поскольку сама сеть Ethernet в принципе непредсказуема вследствиеиспользования случайного метода доступа к среде передачи данных, в отличие,например, от сети IBM Token Ring или ARC Net, в которых используются детерминированные методы доступа.Итак, перечислим основные требования к ОСРВ.Мультипрограммность и мультизадачностьТребование 1.
Операционная система должна быть мультипрограммной и мультизадачной {многопоточной — multi-threaded), а также активно использовать прерывания для диспетчеризации. Как указывалось выше, ОСРВ должна быть предсказуемой. Это означает не то, что ОСРВ должна быть быстрой, а то, что максимальноевремя выполнения того или иного действия должно быть известно заранее и соответствовать требованиям приложения.
Так, например, система Windows 3.11 дажена Pentium IV с частотой более 3000 МГц не может функционировать в качествеОСРВ, ибо одно приложение может практически монопольно захватить центральный процессор и заблокировать систему для остальных вычислений.В соответствии с первым требованием операционная система должна быть многопоточной на принципе абсолютного приоритета (прерываемой). То есть планировщик должен иметь возможность прервать любой поток выполнения и предоставить ресурс тому потоку, которому он более необходим.
Операционная система(и аппаратура) должна также обеспечивать прерывания на уровне обработки прерываний.Приоритеты задачТребование 2. Должно существовать понятие приоритета потока (задачи). Проблема в том, чтобы определить, какой задаче ресурс требуется более всего. В идеальнойситуации ОСРВ отдает ресурс потоку или драйверу с ближайшим крайним сроком,что называется управлением временным ограничением (Deadline DrivenOS). Ч т 0 "бы реализовать это временное ограничение, операционная система должна знать,сколько времени требуется каждому из выполняющихся потоков для завершения.Операционных систем, построенных по этому принципу, практически нет, так какон слишком сложен для реализации.
Поэтому разработчики операционных систелпринимают иную точку зрения: вводится понятие уровня приоритета для задач ,Требования к операционным системам реального времени295временные ограничения сводятся к приоритетам. Так как умозрительные решения чреваты ошибками, показатели СРВ при этом снижаются.
Чтобы более эффективно осуществить указанное преобразование ограничений, проектировщик можетвоспользоваться теорией расписаний или имитационным моделированием, хотя иэто может оказаться бесполезным. Тем не менее, так как на сегодняшний день неимеется иного решения, без понятия приоритета потока не обойтись.иНаследование приоритетовТребование 3.
Должна существовать система наследования приоритетов. На самом деле именно этот механизм синхронизации и тот факт, что различные потокивыполнения используют одно и то же пространство памяти, отличают их от процессов. Как мы уже знаем, процессы не разделяют одно и то же пространство памяти. Так, например, старые версии UNIX не являются многопоточными. «Старая»UNIX — многозадачная ОС, где задачами являются процессы (а не потоки), которые сообщаются через каналы связи (pipes) и разделяемую память. Оба этих механизма используют файловую систему, а ее поведение непредсказуемо.Комбинация приоритетов потоков и разделение ресурсов между ними приводит кдругому явлению — классической проблеме инверсии приоритетов.
Это можнопроиллюстрировать на примере, где есть как минимум три потока. Когда потокнизшего приоритета захватил ресурс, разделяемый с потоком высшего приоритета, и начал выполняться поток среднего приоритета, выполнение потока высшегоприоритета будет приостановлено, пока не освободится ресурс и не отработаетпоток среднего приоритета.
В этой ситуации время, необходимое для завершенияпотока высшего приоритета, зависит от нижних уровней приоритетов — это и естьинверсия приоритетов. Ясно, что в такой ситуации трудно выдержать ограничение на время исполнения.Чтобы устранить такие инверсии, ОСРВ должна допускать наследование приоритета, то есть повышение уровня приоритета потока до уровня потока, который еговызывает.
Наследование означает, что блокирующий ресурс поток наследует приоритет потока, который он блокирует (разумеется, это справедливо лишь в томслучае, если блокируемый поток имеет более высокий приоритет).Иногда можно услышать утверждение, что в грамотно спроектированной системетакая проблема не возникает. В случае сложных систем с этим нельзя согласиться.Единственный способ решения этой проблемы состоит в увеличении приоритетапотока «вручную» прежде, чем ресурс окажется заблокированным.
Разумеется, этовозможно в случае, когда два потока разных приоритетов претендуют на один ресурс В общем случае решения не существует.Сихронизация процессов и задачТребование 4. Операционная система должна обеспечивать мощные, надежные иУдобные механизмы синхронизации задач. Так как задачи разделяют данные (ресурсы) и должны сообщаться друг с другом, представляется логичным существование механизмов блокирования и коммуникации. То есть необходимы механиз-296Глава 9. Архитектура операционных системмы, гарантированно предоставляющие возможность оперативно обменяться сообщениями и синхросигналами между параллельно выполняющимися задачами ипроцессами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
