Операционная система реального времени ( RTOS ) — это операционная система (ОС) для вычислительных приложений реального времени , которая обрабатывает данные и события, имеющие критически определенные временные ограничения. ОСРВ отличается от операционной системы с разделением времени , такой как Unix, которая управляет разделением системных ресурсов с помощью планировщика, буферов данных или фиксированной приоритезации задач в многозадачной или многопрограммной среде. Требования ко времени обработки необходимо полностью понимать и соблюдать, а не просто сводить к минимуму. Вся обработка должна происходить в пределах определенных ограничений. Операционные системы реального времени являются событийно-управляемыми и упреждающими , что означает, что ОС может отслеживать соответствующий приоритет конкурирующих задач и вносить изменения в приоритет задач. Системы, управляемые событиями, переключаются между задачами в зависимости от их приоритетов, а системы с разделением времени переключают задачи на основе прерываний часов . [1]
Ключевой характеристикой ОСРВ является уровень ее согласованности относительно количества времени, необходимого для принятия и выполнения задачи приложения ; изменчивость - это « джиттер ». [2] «Жесткая» операционная система реального времени (жесткая RTOS) имеет меньший джиттер, чем «мягкая» операционная система реального времени (мягкая RTOS). Поздний ответ является неправильным в жесткой ОСРВ, тогда как поздний ответ приемлем в мягкой ОСРВ. Основной целью разработки является не высокая пропускная способность , а скорее гарантия мягкого или жесткого уровня производительности. ОСРВ, которая обычно или в целом может уложиться в срок, представляет собой ОС мягкого реального времени, но если она может детерминированно уложиться в срок , то это ОС жесткого реального времени. [3]
ОСРВ имеет усовершенствованный алгоритм планирования . Гибкость планировщика обеспечивает более широкую оркестровку приоритетов процессов в компьютерной системе, но ОС реального времени чаще предназначена для узкого набора приложений. Ключевыми факторами в ОС реального времени являются минимальная задержка прерывания и минимальная задержка переключения потоков ; ОС реального времени ценится больше за то, насколько быстро и предсказуемо она может реагировать, чем за объем работы, которую она может выполнить за определенный период времени. [4]
ОСРВ — это операционная система, в которой время, необходимое для обработки входного стимула, меньше времени, прошедшего до следующего входного стимула того же типа.
Наиболее распространенными конструкциями являются:
Проекты с разделением времени переключают задачи чаще, чем это необходимо, но обеспечивают более плавную многозадачность , создавая иллюзию, что процесс или пользователь единолично используют машину.
Ранним конструкциям ЦП требовалось много циклов для переключения задач, в течение которых ЦП не мог делать ничего другого полезного. Поскольку переключение занимало так много времени, ранние операционные системы пытались минимизировать потерю процессорного времени, избегая ненужного переключения задач.
В типичных проектах задача имеет три состояния:
Большинство задач большую часть времени заблокированы или готовы, поскольку обычно на каждом ядре ЦП одновременно может выполняться только одна задача . Количество элементов в очереди готовности может сильно различаться в зависимости от количества задач, которые необходимо выполнить системе, и типа планировщика, который использует система. В более простых невытесняющих, но все же многозадачных системах задача должна отдать свое время на ЦП другим задачам, что может привести к тому, что в очереди готовности будет больше общих задач в состоянии готовности к выполнению ( нехватка ресурсов ) . .
Обычно структура данных списка готовности в планировщике рассчитана на минимизацию наихудшего случая пребывания в критической секции планировщика, в течение которого вытеснение запрещается, а в некоторых случаях все прерывания отключаются, но выбор Структура данных зависит также от максимального количества задач, которые могут находиться в списке готовности.
Если в списке готовых задач никогда не бывает более нескольких задач, то оптимальным будет двусвязный список готовых задач. Если список готовых задач обычно содержит лишь несколько задач, а иногда и больше, то список следует отсортировать по приоритету, чтобы для поиска задачи с наивысшим приоритетом для запуска не требовалось обход списка. Вместо этого для вставки задачи требуется пройтись по списку.
Во время этого поиска не следует препятствовать упреждению. Длинные критические секции следует разделить на более мелкие части. Если происходит прерывание, которое делает задачу с высоким приоритетом готовой во время вставки задачи с низким приоритетом, эта задача с высоким приоритетом может быть вставлена и запущена непосредственно перед вставкой задачи с низким приоритетом.
Критическое время ответа, иногда называемое временем обратного хода, — это время, необходимое для постановки в очередь новой готовой задачи и восстановления состояния выполнения задачи с наивысшим приоритетом. В хорошо спроектированной ОСРВ для подготовки новой задачи потребуется от 3 до 20 инструкций на каждую запись в очереди готовности, а для восстановления задачи готовности с наивысшим приоритетом потребуется от 5 до 30 инструкций.
В продвинутых системах задачи реального времени разделяют вычислительные ресурсы со многими задачами, не выполняемыми в реальном времени, и список готовых задач может быть сколь угодно длинным. В таких системах готовый список планировщика, реализованный как связанный список, будет неадекватным.
Некоторые часто используемые алгоритмы планирования RTOS: [5]
Многозадачная операционная система, такая как Unix , плохо справляется с задачами реального времени. Планировщик отдает наивысший приоритет заданиям с наименьшими требованиями к компьютеру, поэтому невозможно гарантировать, что срочные задания будут иметь доступ к достаточному количеству ресурсов. Многозадачные системы должны управлять разделением данных и аппаратных ресурсов между несколькими задачами. Обычно небезопасно, чтобы две задачи одновременно обращались к одним и тем же конкретным данным или аппаратному ресурсу. [6] Существует три распространенных подхода к решению этой проблемы:
Операционные системы общего назначения обычно не позволяют пользовательским программам маскировать (отключать) прерывания , поскольку пользовательская программа может управлять ЦП до тех пор, пока это возможно. Некоторые современные процессоры не позволяют коду пользовательского режима отключать прерывания, поскольку такой контроль считается ключевым ресурсом операционной системы. Однако многие встроенные системы и RTOS позволяют самому приложению работать в режиме ядра для большей эффективности системных вызовов , а также позволяют приложению иметь больший контроль над операционной средой, не требуя вмешательства ОС.
В однопроцессорных системах приложение, работающее в режиме ядра и маскирующее прерывания, является методом с наименьшими издержками для предотвращения одновременного доступа к общему ресурсу. Хотя прерывания маскируются и текущая задача не выполняет блокирующий вызов ОС, текущая задача имеет исключительное использование ЦП, поскольку никакая другая задача или прерывание не может взять на себя управление, поэтому критический раздел защищен. Когда задача выходит из своей критической секции, она должна демаскировать прерывания; ожидающие прерывания, если таковые имеются, будут выполнены. Временное маскирование прерываний следует выполнять только в том случае, если самый длинный путь через критическую секцию короче желаемой максимальной задержки прерывания . Обычно этот метод защиты используется только тогда, когда критическая секция состоит всего из нескольких инструкций и не содержит циклов. Этот метод идеально подходит для защиты аппаратных регистров с битовым отображением, когда биты управляются различными задачами.
Когда общий ресурс необходимо зарезервировать без блокировки всех других задач (например, ожидания записи во флэш-память), лучше использовать механизмы, также доступные в операционных системах общего назначения, такие как мьютекс и межпроцессный обмен сообщениями под контролем ОС. Такие механизмы включают системные вызовы и обычно вызывают код диспетчера ОС при выходе, поэтому для их выполнения обычно требуются сотни инструкций ЦП, в то время как для маскировки прерываний на некоторых процессорах может потребоваться всего одна инструкция.
(Нерекурсивный) мьютекс либо заблокирован , либо разблокирован. Когда задача заблокировала мьютекс, все остальные задачи должны ждать, пока мьютекс будет разблокирован его владельцем — исходным потоком. Задача может установить таймаут ожидания мьютекса. Существует несколько хорошо известных проблем с проектами на основе мьютексов, таких как инверсия приоритетов и взаимоблокировки .
При инверсии приоритетов задача с высоким приоритетом ожидает, поскольку задача с низким приоритетом имеет мьютекс, но задаче с более низким приоритетом не дается процессорное время для завершения своей работы. Типичное решение состоит в том, чтобы задача, владеющая мьютексом, «наследовала» приоритет задачи с наивысшим ожиданием. Но этот простой подход усложняется, когда существует несколько уровней ожидания: задача A ожидает мьютекс, заблокированный задачей B , которая ожидает мьютекс, заблокированный задачей C. Обработка нескольких уровней наследования приводит к тому, что другой код выполняется в контексте с высоким приоритетом и, таким образом, может вызвать истощение потоков со средним приоритетом.
В случае взаимоблокировки две или более задач блокируют мьютекс без тайм-аутов, а затем вечно ждут мьютекс другой задачи, создавая циклическую зависимость. Самый простой сценарий взаимоблокировки возникает, когда две задачи поочередно блокируют два мьютекса, но в обратном порядке. Тупик предотвращается благодаря тщательному проектированию.
Другой подход к совместному использованию ресурсов заключается в отправке сообщений в рамках организованной схемы передачи сообщений . В этой парадигме ресурс управляется напрямую только одной задачей. Когда другая задача хочет запросить ресурс или манипулировать им, она отправляет сообщение управляющей задаче. Хотя их поведение в реальном времени менее четкое, чем у семафорных систем, простые системы на основе сообщений избегают большинства опасностей тупиковой ситуации протокола и, как правило, ведут себя лучше, чем семафорные системы. Однако возможны проблемы, подобные проблемам с семафорами. Инверсия приоритета может произойти, когда задача работает над сообщением с низким приоритетом и игнорирует сообщение с более высоким приоритетом (или сообщение, исходящее косвенно из задачи с высоким приоритетом) в своей очереди входящих сообщений. Взаимные блокировки протокола могут возникать, когда две или более задачи ждут друг от друга отправки ответных сообщений.
Поскольку обработчик прерываний блокирует выполнение задачи с наивысшим приоритетом, а операционные системы реального времени предназначены для сведения задержки потока к минимуму, обработчики прерываний обычно делаются как можно более короткими. Обработчик прерываний, если это возможно, откладывает все взаимодействия с оборудованием; обычно все, что необходимо, — это подтвердить или отключить прерывание (чтобы оно не возникло снова, когда обработчик прерывания вернется) и уведомить задачу о том, что работу необходимо выполнить. Это можно сделать, разблокировав задачу драйвера путем освобождения семафора, установки флага или отправки сообщения. Планировщик часто предоставляет возможность разблокировать задачу из контекста обработчика прерываний.
ОС поддерживает каталоги объектов, которыми она управляет, таких как потоки, мьютексы, память и т. д. Обновления данного каталога должны строго контролироваться. По этой причине может возникнуть проблема, когда обработчик прерываний вызывает функцию ОС, когда приложение также выполняет это. Функция ОС, вызванная из обработчика прерываний, могла обнаружить, что база данных объектов находится в несогласованном состоянии из-за обновления приложения. Существует два основных подхода к решению этой проблемы: унифицированная архитектура и сегментированная архитектура. ОСРВ, реализующие унифицированную архитектуру, решают проблему, просто отключая прерывания на время обновления внутреннего каталога. Обратной стороной этого является увеличение задержки прерываний, что может привести к потере прерываний. Сегментированная архитектура не выполняет прямых вызовов ОС, а делегирует работу, связанную с ОС, отдельному обработчику. Этот обработчик работает с более высоким приоритетом, чем любой поток, но ниже, чем обработчики прерываний. Преимущество этой архитектуры в том, что она добавляет очень мало циклов к задержке прерывания. В результате операционные системы, реализующие сегментированную архитектуру, более предсказуемы и могут справляться с более высокой частотой прерываний по сравнению с унифицированной архитектурой. [ нужна цитата ]
Аналогичным образом, режим управления системой на оборудовании, совместимом с x86, может занять много времени, прежде чем он вернет управление операционной системе.
Распределение памяти более важно в операционной системе реального времени, чем в других операционных системах.
Во-первых, для стабильности не может быть утечек памяти (памяти, которая выделяется, но не освобождается после использования). Устройство должно работать бесконечно, без необходимости перезагрузки. По этой причине динамическое выделение памяти не одобряется. [ нужна цитата ] По возможности, все необходимое выделение памяти указывается статически во время компиляции.
Еще одна причина избегать динамического выделения памяти — фрагментация памяти. При частом выделении и освобождении небольших кусков памяти может возникнуть ситуация, когда доступная память делится на несколько разделов и ОСРВ не может выделить достаточно большой непрерывный блок памяти, хотя свободной памяти достаточно. Во-вторых, важна скорость распределения. Стандартная схема распределения памяти сканирует связанный список неопределенной длины, чтобы найти подходящий блок свободной памяти, [7] что неприемлемо в ОСРВ, поскольку выделение памяти должно происходить в течение определенного периода времени.
Поскольку механические диски имеют гораздо более длительное и непредсказуемое время отклика, замена файлов на диске не используется по тем же причинам, что и распределение оперативной памяти, описанное выше.
Простой алгоритм блоков фиксированного размера вполне хорошо работает для простых встроенных систем из-за его низких накладных расходов.
