Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Операционные системы реального времени и технологии разработки кроссплатформенного программного обеспечения. Ч.1. Учебное пособие
.pdf
6.4. Особенности управления памятью в операционных системах реального…
121
1. Даже если все страницы виртуальной памяти загружены и отоб-
ражаются в физическую память, то вносимая во время трансляции адресов
задержка не является определенной заранее, т.е. ожидаемой. Эта “пауза”
между операциями зависит от нескольких факторов, например, находится
ли страница в кэше трансляции страниц, был ли уже ранее рассчитан и закэширован адрес и т.д.
2. Если некоторые страницы виртуальной памяти находятся за пре-
делами физической памяти и находятся на внешнем носителе, то задержка,
связанная с трансляцией адресов, не только не является определенной, но
и может быть очень большой. Это также зависит от многих факторов,
например от размеров требуемой программе памяти, скорости чтения диска
и занятости системы в целом.
Для того чтобы уменьшить эффект задержки, в операционных систе-
мах реального времени существуют специальные системные вызовы, сохраняющие (кэширующие) ранее загружаемые страницы в физической памяти с запретом переноса на внешний дисковый накопитель.
Время задержки на переключение контекста потока напрямую зави-
сит от конфигурации памяти, т.е. от Модели защиты памяти, которая
строго соблюдается в системе. Можно привести примеры наиболее часто
применяемых моделей работы с памятью.
1. Модель памяти без защиты.
2. Модель защиты Система–Пользователь.
3. Модель защиты Пользователь–Пользователь.
4. Модель защиты виртуальной памяти.
Согласно Модели памяти без защиты, которая часто применялась в
ранних операционных системах (например, в MS DOS), системное адресное пространство и пользовательское пространство никак не изолировались друг от друга. Здесь применялось два сегмента памяти, называемые
Сегмент кода и Сегмент данных. Метки этих Сегментов напрямую размещались в файле программы. Например, на языке Ассемблер применялись
аббревиатуры dataseg, codeseg. То же самое происходило и с сегментом
стека (stack). В этом подходе не требовалось специальное аппаратное
устройство для поддержки виртуальной памяти и контроля доступа к областям памяти. Программа исполнялась одна на фоне системных вызовов.
6. Управление памятью
122
Модель защиты Система–Пользователь подразумевает, что системное адресное пространство изолируется и защищается от адресного пространства пользователя. Системные и пользовательские процессы выполняются уже в общем виртуальном адресном пространстве, и при этом требуется аппаратная система управления памятью MMU (Memory
management unit). При этом используются страничные механизмы доступа
и соответственно защиты памяти. Различают системные и пользовательские страницы. Однако пользовательские страницы никак не защищаются
друг от друга. Процессор находится в режиме супервизора и работает с сегментами, оценивая уровень привилегий текущего сегмента задачи. Принято различать четыре уровня привилегий с номерами от 0 до 3. Пользовательский (самый низкий) уровень привилегий – 3. Уровни от 0 до 2 принадлежат сегментам кода и являются системными. В такой модели механизм
страничного доступа не добавляет никаких накладных расходов к процессу
управления памятью, так как защита срабатывает одновременно с преобразованием адреса. А преобразование адреса проводит MMU и при этом сама
операционная система в этом процессе непосредственно не участвует.
Модель защиты Пользователь–Пользователь добавляет к модели защиты Система–Пользователь дополнительный уровень, реализуемый совместно с MMU. Как и в предыдущем случае, применяется страничный механизм управления памятью. Все страницы помечаются как привилегированные за исключением страниц текущего исполняемого процесса, которые помечаются как пользовательские. Таким образом, решается ситуация,
что выполняющийся поток находится в окружении страниц другого уровня
и не может обратиться за пределы своего адресного пространства. В этом
процессе операционная система отвечает за обновление флага привилегированности для конкретной страницы. Обновление проводится для страницы в специальной таблице при переключении процесса.
Модель защиты виртуальной памяти описывает выполнение каждого процесса в своей собственной виртуальной памяти. Здесь также требуется активная работа MMU. Каждый процесс использует свои собственные сегменты, а следовательно, и свои собственные таблицы с описанием
сегментов. Операционная система в этой модели занимается поддержкой
описательных таблиц сегментов. Используемое процессами адресное про-
6.4. Особенности управления памятью в операционных системах реального…
123
странство может превышать размеры физической памяти, так как применяется страничная организация памяти совместно с механизмом подкачки.
В чистых операционных системах реального времени подкачка обычно не
применяется в связи с непредсказуемостью этого процесса. Поэтому доступная память разбивается на фиксированное множество логических адресных пространств одинакового размера. При этом число одновременно
выполняемых процессов становится ограниченным.
Следует также упомянуть, что для операционных систем реального
времени очень важно выполнять требования ограниченности времени доступа к оперативной памяти. Память является разделяемым ресурсом и, как
любой разделяемый ресурс ОС РВ, требует детерминированности.
Следствием этого ограничения является запрет механизмов вызова
страниц по запросу, т.е. механизмов подкачки, поэтому ОС РВ просто блокирует вызов страницы от процесса в оперативной памяти.
Если применяется страничная организация памяти, то поддержка
отображения страниц на физические адреса становится частью контекста
обработки процесса. Если процесс не является процессом жесткого реального времени, то можно применять механизм динамического распределения памяти, но при этом ОС РВ должна поддерживать обработку временных задержек при работе с памятью, выравнивая и предсказывая их. То есть
ОС должна обеспечивать предсказуемое время ожидания.
В обычных операционных системах без жестких требований к реальному времени, применяется механизм сегментации памяти для борьбы с
фрагментацией, т.е. с процессом нарушения регулярности распределения ад-
ресов по физическому адресному пространству. Эта процедура называется
уплотнением памяти после сборки мусора. А под сборкой мусора понимается освобождение памяти, выделенной под переменные программ после
того, как они перестают быть нужными в системе или выгружаются. Языки
программирования системного уровня типа С++ не имеют автоматической
сборки мусора, тогда как прикладные языки типа C# или Java имеют собственные системы очистки, называемые сборщиками (garbage collectors). Так
как процесс очистки сопровождается фрагментацией памяти и занимает недетерминированное время, то такие языки не подходят на роль основных
языков разработки приложений для систем реального времени.
6. Управление памятью
124
В системах жесткого реального времени обычно применяются ме-
тоды статического распределения памяти. В системах мягкого реального
времени возможно применение динамического распределения памяти без
виртуализации и уплотнения.
6.5. Устройство управления памятью
(Memory Management Unit, MMU)
Это блок управления памятью MMU, который является компонентом
аппаратного обеспечения вычислительного устройства. Он отвечает за
управление доступом к памяти и контролируется центральным процессором.
MMU обеспечивает выполнение следующих основных функций:
трансляция адреса при помощи TLB (Translation LookUp Buffer)
– специального буфера быстрого преобразования адреса. Этот буфер представляет собой специальную аппаратную таблицу (находящуюся внутри
самого устройства), которая применяется для преобразования виртуального адреса в физический и наоборот;
вызов страниц по требованию, если такой механизм поддержива-
ется системой. Вызов работает по сигналу ошибки вследствие отсутствия
страницы в основной памяти;
защита адресов при помощи специального режима, обеспечива-
ется несколькими способами защиты: реальный режим, защищенный режим и т.д. Для каждого диапазона памяти может быть применен различный
режим защиты;
управление кэшем;
арбитраж шин;
переключение блоков памяти.
Иногда MMU упоминается в документации как блок управления ста-
тической памятью (Paged MMU). Его принцип работы основан на разделении виртуального адресного пространства на участки одинакового размера
(рис. 13), называемого страницами.
Тогда память воспринимается как отражение одномерного массива
адресов, используемого центральным процессором. Размер страницы фиксируется равным нескольким килобайтам, хотя возможно применение
страниц большего размера, определяемого степенью числа 2.
6.5. Устройство управления памятью (Memory Management Unit, MMU)
125
Рис. 13. Схема работы MMU
Младшие биты адреса, определяющие смещение внутри страницы,
в этом случае остаются неизменными. Старшие биты адреса интерпретируются как номер виртуальной страницы и используются для страничных
операций. MMU обычно преобразует номера виртуальных страниц в физические с применением буфера ассоциативной трансляции TLB (Translation
Lookaside Buffer), в котором некоторое время хранятся уже ранее сформированные отображения. Также для систем обслуживание буфера характерно применение алгоритмов сортировки и распознавание адресов.
Если преобразование при помощи TLB (аппаратно) невозможно, то
подключается более медленный механизм преобразования адресов, результат которого пополняет или изменяет TLB. Данные в этих таблицах называются элементами таблицы страниц PTE (Page Table Entries), а сами структуры – таблицами страниц PT (Page Table). Объединение номера физической
страницы со смещением внутри страницы определяет физический адрес.
Также в таблицах могут содержаться дополнительные данные,
например, признак записи в страницу, который применяется для определения времени последнего использования страниц для алгоритма замещения
страниц, признак того, какие процессы могут читать и записывать данные
в страницу (пользовательские или системные), признак необходимости кэшировать страницу и так далее.
Сейчас наиболее часто MMU уже включен в состав центрального
процессора и не требует реализации в виде отдельной микросхемы.
7. Отказоустойчивость операционных систем реального времени
126
7. ОТКАЗОУСТОЙЧИВОСТЬ ОПЕРАЦИОННЫХ
СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ
7.1. Понятие отказоустойчивости системы
Условия применения ОС РВ накладывает определенные требования
на ее устойчивость, надежность и способность работать в критических ситуациях. Любой отказ в работе системы может привести не только к простою системы, некорректности результатов вычислений или их отсутствию, но и к критическим последствиям. Продолжительное бездействие
системы или постоянные ошибки могут привести к аварии или к техногенной катастрофе. Преимущество использования отказоустойчивых систем
как раз и вытекает из необходимости продолжительной надежной работы в
любых условиях, особенно когда техническое обслуживание или ремонт в
любое время невозможен, когда доступ к системе ограничен или условия
эксплуатации опасны для здоровья или жизни персонала.
Поэтому все отказоустойчивые системы разрабатываются изначально так, чтобы система была “терпима” к отказам и даже могла восстанавливаться самостоятельно. Отдельные экземпляры ОС РВ и систем вообще работают без перезагрузки и обслуживания годами и даже десятилетиями, чего не скажешь об обычных системах, нацеленных на стандартного
потребителя.
Сложность современных вычислительных систем такова, что даже
сама возможность проверить работоспособность системы в реальных критических ситуациях является невозможной. Максимум что можно сделать, так
это провести симуляцию и проводить разработку в моделируемых условиях.
Это в некоторых случаях позволяет выявить ошибки разработки программных и аппаратных средств до введения системы в эксплуатацию и
принять меры по их своевременному устранению.
Сами по себе отказы могут быть периодическими или случайными,
внутренними или возникающими под влиянием внешних факторов. Могут
быть помехи, паразитные импульсы или всплески, брак производства аппаратных устройств и программные ошибки. В любом случае, каждая такая
ситуация тщательно изучается и принимаются соответствующие меры по
ликвидации уязвимости системы.
7.2. Основные причины сбоев вычислительной системы
127
7.2. Основные причины сбоев вычислительной системы
К основным причинам возникновения сбоев можно отнести кон-
струкционные или эксплуатационные риски.
Эксплуатационные риски возникают при неправильной эксплуата-
ции, т.е. при применении в нормальной или критической ситуации с ненадлежащим циклом и составом параметров эксплуатации. В этой связи, выделяют понятие “надежности” системы как способности функционировать
даже при наличии определенных ошибок аппаратного или программного
характера.
Отказ при исполнении системой основных функций может про-
явиться вследствие следующих причин:
нарушение кодов программ, например, при загрузке их в опера-
тивную память с внешних носителей;
стирание или искажение данных в процессе работы в оператив-
ном, постоянном запоминающих устройствах или в каналах связи:
нарушение нормального хода вычислительного процесса.
Примечательно то, что перечисленные выше причины могут возникать как обособленно, так и все вместе. Отказ системы может проявиться в
виде программного сбоя, нарушения алгоритма, пропуска команд, перехода по неправильному адресу, однократного или систематического нарушения данных и т.д.
Программные отказы приводят в основном к прекращению выдачи
потребителям нужных им данных или к прекращению обслуживания.
Аппаратные отказы могут привести вообще к краху всей системы и
к появлению программных ошибок. Программные ошибки приводят к появлению аппаратных достаточно редко. Единственным распространенным
примером является сбой в системе управления целевой системы и, как
следствие, переход системы в критические состояния (например, сбой системы вентиляции, охлаждения, питания).
Обеспечить устойчивость системы на программном уровне гораздо
сложнее, чем на аппаратном. Рассматривая подробнее аппаратные сбои,
можно выделить следующие основные классы отказов системы с точки зрения аппаратуры:
отказ микропроцессора или другого важного элемента системы;
7. Отказоустойчивость операционных систем реального времени
128
отказ каналов связи между важными элементами системы;
отказ систем обеспечения работоспособности и систем обслужи-
вания основной системы.
Разработчики стараются включить в системы средства идентифика-
ции отказа и выявления его причины. Подобные данные позволяют собирать статистику и разрабатывать новые методы и средства защиты систем,
как на аппаратном, так и на программном уровне.
Например, отказ коммуникационной системы, приводящий к потере
определенной степени связанности второстепенных компонентов системы,
может привести к фатальному исходу, если связь нарушена с центральными элементами. В качестве одного из возможных решений применяют
дублирование и резервирование каналов связи, что позволяет при сбое
быстро реинициализировать коммуникационную среду и направить потоки
данных и команд управления по другим каналам к тем же самым элементам
системы.
Предсказать системный сбой можно, но предсказать случайные или
“блуждающие” ошибки практически невозможно. Можно лишь оценить
вероятность возникновения такого сбоя и тщательно к нему подготовиться.
С течением времени и с усложнением систем появляется все больше вероятных источников опасности для системы. В конце концов, задача разработчиков – создать систему, для которой была бы определена реакция на
любую вероятную или случайную ошибку.
Таким образом, сбой будет приводить к ожидаемому поведению системы, как и в случае нормального поведения.
Такой спектр мер способен обеспечить безотказную работу системы
в любой вообразимой ситуации.
7.3. Элементы отказоустойчивости системы
Существует множество элементов или компонент отказоустойчивой
системы.
Одним из самых популярных является изоляция системы в целом
или изоляция ее отдельных компонент. Основной принцип изоляции заключается в том, что ни один из компонент, работающих нормально или
7.3. Элементы отказоустойчивости системы
129
со сбоями, не может нарушить работоспособность других компонент системы.
Обычно такая цель достигается путем построения системы из от-
дельных блоков со слабыми связями. При этом стандартно она решается
внедрением дополнительных блоков управления памятью (диспетчеров) и
введением пользовательских и системных программных интерфейсов
(API), нередко с разграничением прав доступа.
При нарушении целостности системы или при нарушении прав до-
ступа к информации, механизм отключает проблемный компонент и перезапускает его.
Исключительная ситуация может быть реализована в отдельном ад-
ресном пространстве приложения и никак не повлияет на работоспособность системы в целом.
Также существует несколько важных элементов отказоустойчивости
системы, которые гарантируют ее надежность при совместном или раздельном применении:
восстановление ресурсов;
режим пользователя/супервизора;
защита от чрезмерного расходования ресурсов.
Восстановление ресурсов выполняется после окончания работы прикладной программы, которая завершилась по плану или вследствие сбоя.
Выделенные ей ресурсы возвращаются обратно в систему и становятся доступны другим приложениям. Исключение составляют ресурсы, которые
помечены как резервные. При отсутствии этой возможности, ОС РВ быстро
исчерпает свободные ресурсы и ее необходимо перезагружать. Учитывая
требуемый высокий уровень качества обслуживания, эта ситуация неприемлема на практике. Даже во время модернизации системы или ее обновления, должны оставаться свободные ресурсы и возможность их перераспределять. При этом стараются сделать ресурс и обслуживающий сервис
максимально независимыми друг от друга. Например, сервер приложений,
который обслуживает множество клиентов, может быть быстро перезагружен или вообще заменен без ущерба для клиентов, потому что сами клиенты совершенно не в курсе какой сервер запущен и как он работает. Для
них важно только то, что их задания выполняются, а ресурсы предоставляются по очереди или по требованию.
7. Отказоустойчивость операционных систем реального времени
130
Пользовательский режим и режим супервизора работает в том слу-
чае, когда приложения исполняются либо в “системном” режиме, либо в
режиме “супервизора”, т.е. ему становятся доступны некоторые операции,
которые недостижимы для обычных приложений. Следует, однако, помнить, что применение режима супервизора сопряжено с вероятностью появления необратимых последствий. Операционная система должна обладать достаточной гибкостью, чтобы обеспечить создание привилегированных процессов, которые могут переходить в режим супервизора и потом
возвращаться обратно в обычный режим пользователя.
Защита от перерасхода ресурсов применяется тогда, когда часть при-
ложений пишется без автоматического контроля над используемыми ресурсами. Отсутствие контроля может, в конце концов, вырасти в неконтролируемое “клонирование” и “размножение” выполняемых процессов, снижение надёжности, нехватку ресурсов. Защита заключается во внедрении в
систему таких элементов, которые могли бы следить за процессами и задачами, контролировать ресурсы и их распределение по потребителям.
Большую надежность и отказоустойчивость системы можно достичь
в определенных пределах путем внедрения режимов работы: “мягкого” (с
выдачей предупреждений) или “жесткого” (с выделением сигналов, например, о нехватке ресурсов) порогов, при достижении которых запускаются
действия по восстановлению работоспособности системы.
7.4. Способы обеспечения отказоустойчивости системы
Для обеспечения надежной работы системы и ожидаемого выполнения задач в условиях случайных и систематических сбоев в основном применяются следующие два подхода:
восстановление или возобновление задачи после сбоя системы;
предотвращение отказа системы.
Первый подход заключается во внедрении дополнительных механизмов прямого и возвратного восстановления задачи. Прямое восстановление выполняется без восстановления предыдущего состояния, т.е. задача
запускается заново с переходом к следующему состоянию. Прямое восстановление основано на своевременном обнаружении сбоя. Такое восстанов-
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]