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