Операционная система реального времени

Операционная система реального времени ( RTOS ) — это операционная система (ОС) для вычислительных приложений реального времени , которая обрабатывает данные и события, имеющие критически определенные временные ограничения. ОСРВ отличается от операционной системы с разделением времени , такой как Unix, которая управляет разделением системных ресурсов с помощью планировщика, буферов данных или фиксированной приоритезации задач в многозадачных или многопрограммных средах. Требования ко времени обработки необходимо полностью понимать и соблюдать, а не просто сводить к минимуму. Вся обработка должна происходить в пределах определенных ограничений. Операционные системы реального времени являются событийно-управляемыми и упреждающими , что означает, что ОС может отслеживать соответствующий приоритет конкурирующих задач и вносить изменения в приоритет задач. Системы, управляемые событиями, переключаются между задачами в зависимости от их приоритетов, а системы с разделением времени переключают задачи на основе прерываний часов . ^{[ 1 ]}

Характеристики

приложения Ключевой характеристикой ОСРВ является уровень ее согласованности относительно количества времени, необходимого для принятия и выполнения задачи ; изменчивость – это « джиттер ». ^{[ 2 ]} «Жесткая» операционная система реального времени (жесткая RTOS) имеет меньший джиттер, чем «мягкая» операционная система реального времени (мягкая RTOS); поздний ответ является неправильным в жесткой ОСРВ, тогда как поздний ответ приемлем в мягкой ОСРВ. Основной целью разработки является не высокая пропускная способность , а скорее гарантия мягкого или жесткого уровня производительности. ОСРВ, которая обычно или вообще может уложиться в срок, представляет собой ОС мягкого реального времени, но если она может детерминированно уложиться в срок, то это ОС жесткого реального времени. ^{[ 3 ]}

ОСРВ имеет усовершенствованный алгоритм планирования . Гибкость планировщика обеспечивает более широкую оркестровку приоритетов процессов в компьютерной системе, но ОС реального времени чаще предназначена для узкого набора приложений. Ключевыми факторами в ОС реального времени являются минимальная задержка прерывания и минимальная задержка переключения потоков ; ОС реального времени ценится больше за то, насколько быстро и предсказуемо она может реагировать, чем за объем работы, которую она может выполнить за определенный период времени. ^{[ 4 ]}

Философия дизайна

ОСРВ — это операционная система, в которой время, необходимое для обработки входного стимула, меньше времени, прошедшего до следующего входного стимула того же типа.

Наиболее распространенными конструкциями являются:

Управляемый событиями – переключает задачи только тогда, когда событие с более высоким приоритетом требует обслуживания; называется вытесняющим приоритетом или приоритетным планированием.
Разделение времени — переключает задачи по обычному тактовому прерыванию и по событиям; называется циклическим .

Проекты с разделением времени переключают задачи чаще, чем это необходимо, но обеспечивают более плавную многозадачность , создавая иллюзию того, что процесс или пользователь единолично используют машину.

Ранним конструкциям ЦП требовалось много циклов для переключения задач, в течение которых ЦП не мог делать ничего другого полезного. Поскольку переключение занимало так много времени, ранние операционные системы пытались минимизировать потерю процессорного времени, избегая ненужного переключения задач.

Планирование

В типичных проектах задача имеет три состояния:

Запуск (выполнение на процессоре);
Готово (готово к исполнению);
Заблокировано (ожидание события, например ввода-вывода).

одновременно может выполняться только одна задача ЦП Большинство задач большую часть времени заблокированы или готовы, поскольку обычно на каждом ядре . Количество элементов в очереди готовности может сильно различаться в зависимости от количества задач, которые необходимо выполнить системе, и типа планировщика, который использует система. В более простых невытесняющих, но все же многозадачных системах задача должна отдать свое время на ЦП другим задачам, что может привести к тому, что в очереди готовности будет больше общих задач в состоянии готовности к выполнению ( нехватка ресурсов ). .

Обычно структура данных списка готовности в планировщике рассчитана на минимизацию наихудшего случая пребывания в критической секции планировщика, в течение которого вытеснение запрещается, а в некоторых случаях все прерывания отключаются, но выбор Структура данных зависит также от максимального количества задач, которые могут находиться в списке готовности.

Если в списке готовых задач никогда не бывает более нескольких задач, то двусвязный список оптимальным будет готовых задач. Если список готовых задач обычно содержит лишь несколько задач, а иногда и больше, то список следует отсортировать по приоритету, чтобы для поиска задачи с наивысшим приоритетом для запуска не требовалось обход списка. Вместо этого для вставки задачи требуется пройтись по списку.

Во время этого поиска не следует препятствовать упреждению. Длинные критические секции следует разделить на более мелкие части. Если происходит прерывание, которое делает задачу с высоким приоритетом готовой во время вставки задачи с низким приоритетом, эта задача с высоким приоритетом может быть вставлена и запущена непосредственно перед вставкой задачи с низким приоритетом.

Критическое время ответа, иногда называемое временем обратного хода, — это время, необходимое для постановки в очередь новой готовой задачи и восстановления состояния выполнения задачи с наивысшим приоритетом. В хорошо спроектированной ОСРВ для подготовки новой задачи потребуется от 3 до 20 инструкций на каждую запись в очереди готовности, а для восстановления задачи готовности с наивысшим приоритетом потребуется от 5 до 30 инструкций.

В продвинутых системах задачи реального времени разделяют вычислительные ресурсы со многими задачами, не выполняемыми в реальном времени, и список готовых задач может быть сколь угодно длинным. В таких системах готовый список планировщика, реализованный как связанный список, будет неадекватным.

Алгоритмы

Некоторые часто используемые алгоритмы планирования RTOS: ^{[ 5 ]}

Совместное планирование
Упреждающее планирование
- Монотонное планирование
- Круговое планирование
- Упреждающее планирование с фиксированным приоритетом , реализация упреждающего квантования времени.
- Планирование с фиксированным приоритетом и отложенным приоритетом
- Невытесняющее планирование с фиксированным приоритетом
- Упреждающее планирование критической секции
- Статическое планирование времени
«Первый срок» Самый ранний подход
Стохастические орграфы с многопоточным обходом графа

Межзадачное общение и совместное использование ресурсов

Многозадачная операционная система, такая как Unix, плохо справляется с задачами реального времени. Планировщик отдает наивысший приоритет заданиям с наименьшими требованиями к компьютеру, поэтому невозможно гарантировать, что срочные задания будут иметь доступ к достаточному количеству ресурсов. Многозадачные системы должны управлять разделением данных и аппаратных ресурсов между несколькими задачами. Обычно небезопасно, чтобы две задачи одновременно обращались к одним и тем же конкретным данным или аппаратному ресурсу. ^{[ 6 ]} Существует три распространенных подхода к решению этой проблемы:

Временное маскирование/отключение прерываний

Операционные системы общего назначения обычно не позволяют пользовательским программам маскировать (отключать) прерывания , поскольку пользовательская программа может управлять ЦП до тех пор, пока это возможно. Некоторые современные процессоры не позволяют коду пользовательского режима отключать прерывания, поскольку такой контроль считается ключевым ресурсом операционной системы. Однако многие встроенные системы и RTOS позволяют самому приложению работать в режиме ядра для большей эффективности системных вызовов , а также позволяют приложению иметь больший контроль над операционной средой, не требуя вмешательства ОС.

В однопроцессорных системах приложение, работающее в режиме ядра и маскирующее прерывания, является методом с наименьшими издержками для предотвращения одновременного доступа к общему ресурсу. Хотя прерывания маскируются и текущая задача не выполняет блокирующий вызов ОС, текущая задача имеет исключительное использование ЦП, поскольку никакая другая задача или прерывание не может взять на себя управление, поэтому критический раздел защищен. Когда задача выходит из своей критической секции, она должна демаскировать прерывания; ожидающие прерывания, если таковые имеются, будут выполнены. Временное маскирование прерываний следует выполнять только в том случае, если самый длинный путь через критическую секцию короче желаемой максимальной задержки прерывания . Обычно этот метод защиты используется только тогда, когда критическая секция состоит всего из нескольких инструкций и не содержит циклов. Этот метод идеально подходит для защиты аппаратных битовых регистров, когда биты управляются различными задачами.

Мьютексы

Когда общий ресурс необходимо зарезервировать без блокировки всех других задач (например, ожидания записи во флэш-память), лучше использовать механизмы, также доступные в операционных системах общего назначения, такие как мьютекс и межпроцессный обмен сообщениями под контролем ОС. Такие механизмы включают в себя системные вызовы и обычно вызывают код диспетчера ОС при выходе, поэтому для их выполнения обычно требуются сотни инструкций ЦП, в то время как для маскировки прерываний на некоторых процессорах может потребоваться всего одна инструкция.

(Нерекурсивный) мьютекс либо заблокирован , либо разблокирован. Когда задача заблокировала мьютекс, все остальные задачи должны ждать, пока мьютекс будет разблокирован его владельцем — исходным потоком. Задача может установить таймаут ожидания мьютекса. Существует несколько хорошо известных проблем с проектами на основе мьютексов, таких как инверсия приоритетов и взаимоблокировки .

При инверсии приоритетов задача с высоким приоритетом ожидает, поскольку задача с низким приоритетом имеет мьютекс, но задаче с более низким приоритетом не дается процессорное время для завершения своей работы. Типичное решение состоит в том, чтобы задача, владеющая мьютексом, «наследовала» приоритет задачи с наивысшим ожиданием. Но этот простой подход усложняется, когда существует несколько уровней ожидания: задача A ожидает мьютекс, заблокированный задачей , которая ожидает мьютекс, заблокированный задачей C. B Обработка нескольких уровней наследования приводит к тому, что другой код выполняется в контексте с высоким приоритетом и, таким образом, может вызвать истощение потоков со средним приоритетом.

В случае взаимоблокировки две или более задач блокируют мьютекс без тайм-аутов, а затем вечно ждут мьютекс другой задачи, создавая циклическую зависимость. Самый простой сценарий взаимоблокировки возникает, когда две задачи поочередно блокируют два мьютекса, но в обратном порядке. Тупик предотвращается благодаря тщательному проектированию.

Передача сообщений

Другой подход к совместному использованию ресурсов заключается в отправке сообщений в рамках организованной схемы передачи сообщений . В этой парадигме ресурс управляется напрямую только одной задачей. Когда другая задача хочет запросить ресурс или манипулировать им, она отправляет сообщение управляющей задаче. Хотя их поведение в реальном времени менее четкое, чем у семафорных систем, простые системы на основе сообщений избегают большинства опасностей тупиковой ситуации протокола и, как правило, ведут себя лучше, чем семафорные системы. Однако возможны проблемы, подобные проблемам семафоров. Инверсия приоритета может произойти, когда задача работает над сообщением с низким приоритетом и игнорирует сообщение с более высоким приоритетом (или сообщение, исходящее косвенно из задачи с высоким приоритетом) в своей очереди входящих сообщений. Взаимные блокировки протокола могут возникать, когда две или более задачи ждут друг от друга отправки ответных сообщений.

Обработчики прерываний и планировщик

Поскольку обработчик прерываний блокирует выполнение задачи с наивысшим приоритетом, а операционные системы реального времени предназначены для сведения задержки потока к минимуму, обработчики прерываний обычно делаются как можно более короткими. Обработчик прерываний, если это возможно, откладывает все взаимодействия с оборудованием; обычно все, что необходимо, — это подтвердить или отключить прерывание (чтобы оно не возникло снова, когда обработчик прерывания вернется) и уведомить задачу о том, что необходимо выполнить работу. Это можно сделать, разблокировав задачу драйвера путем освобождения семафора, установки флага или отправки сообщения. Планировщик часто предоставляет возможность разблокировать задачу из контекста обработчика прерываний.

ОС поддерживает каталоги объектов, которыми она управляет, таких как потоки, мьютексы, память и т. д. Обновления данного каталога должны строго контролироваться. По этой причине может возникнуть проблема, когда обработчик прерываний вызывает функцию ОС, когда приложение также выполняет это. Функция ОС, вызванная из обработчика прерываний, могла обнаружить, что база данных объектов находится в несогласованном состоянии из-за обновления приложения. Существует два основных подхода к решению этой проблемы: унифицированная архитектура и сегментированная архитектура. ОСРВ, реализующие унифицированную архитектуру, решают проблему, просто отключая прерывания во время обновления внутреннего каталога. Обратной стороной этого является увеличение задержки прерываний, что может привести к потере прерываний. Сегментированная архитектура не выполняет прямых вызовов ОС, а делегирует работу, связанную с ОС, отдельному обработчику. Этот обработчик работает с более высоким приоритетом, чем любой поток, но с более низким, чем обработчики прерываний. Преимущество этой архитектуры в том, что она добавляет очень мало циклов к задержке прерывания. В результате операционные системы, реализующие сегментированную архитектуру, более предсказуемы и могут справляться с более высокой частотой прерываний по сравнению с унифицированной архитектурой. ^{[ нужна ссылка ]}

Аналогичным образом, режим управления системой на оборудовании, совместимом с x86, может занять много времени, прежде чем он вернет управление операционной системе.

Распределение памяти

Распределение памяти более важно в операционной системе реального времени, чем в других операционных системах.

Во-первых, для стабильности не может быть утечек памяти (памяти, которая выделяется, но не освобождается после использования). Устройство должно работать бесконечно, без необходимости перезагрузки. По этой причине динамическое выделение памяти не одобряется. ^{[ нужна ссылка ]} По возможности все необходимое выделение памяти указывается статически во время компиляции.

Еще одна причина избегать динамического выделения памяти — фрагментация памяти. При частом выделении и освобождении небольших кусков памяти может возникнуть ситуация, когда доступная память делится на несколько разделов и ОСРВ не может выделить достаточно большой непрерывный блок памяти, хотя свободной памяти достаточно. Во-вторых, важна скорость распределения. Стандартная схема распределения памяти сканирует связанный список неопределенной длины, чтобы найти подходящий свободный блок памяти. ^{[ 7 ]} что неприемлемо в ОСРВ, поскольку выделение памяти должно происходить в течение определенного периода времени.

Поскольку механические диски имеют гораздо более длительное и непредсказуемое время отклика, замена файлов на диске не используется по тем же причинам, что и распределение оперативной памяти, описанное выше.

Простой алгоритм блоков фиксированного размера вполне хорошо работает для простых встроенных систем из-за его низких накладных расходов.

См. также

Ссылки

^ «Операционные системы реального времени (ОСРВ)» . Бензинга . 13 сентября 2023 г. Проверено 13 сентября 2023 г.
^ «Время отклика и джиттер» . Архивировано из оригинала 23 июля 2011 г. Проверено 4 декабря 2010 г.
^ Таненбаум, Эндрю (2008). Современные операционные системы . Река Аппер-Сэддл, Нью-Джерси: Пирсон/Прентис-Холл. п. 160. ИСБН 978-0-13-600663-3 .
^ «Концепции ОСРВ» . Архивировано из оригинала 23 июля 2011 г. Проверено 4 декабря 2010 г.
^ Самек, Миро (23 мая 2023 г.). «Программирование встроенных систем: ОСРВ – что такое режим реального времени?» . Встроенный.com . Проверено 13 сентября 2023 г.
^ Франер, Ральф А. (осень 1984 г.). «Будущее Unix на IBM PC» . Байт . стр. 59–64.
^ «CS 241, Университет Иллинойса» (PDF) .

[1] «Операционные системы реального времени (ОСРВ)» . Бензинга . 13 сентября 2023 г. Проверено 13 сентября 2023 г.

[2] «Время отклика и джиттер» . Архивировано из оригинала 23 июля 2011 г. Проверено 4 декабря 2010 г.

[Tanenbaum-3] Таненбаум, Эндрю (2008). Современные операционные системы . Река Аппер-Сэддл, Нью-Джерси: Пирсон/Прентис-Холл. п. 160. ИСБН 978-0-13-600663-3 .

[4] «Концепции ОСРВ» . Архивировано из оригинала 23 июля 2011 г. Проверено 4 декабря 2010 г.

[5] Самек, Миро (23 мая 2023 г.). «Программирование встроенных систем: ОСРВ – что такое режим реального времени?» . Встроенный.com . Проверено 13 сентября 2023 г.

[phraner1984fall-6] Франер, Ральф А. (осень 1984 г.). «Будущее Unix на IBM PC» . Байт . стр. 59–64.

[7] «CS 241, Университет Иллинойса» (PDF) .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

v т и Встраиваемые системы
Общие условия	ASIC Пакет поддержки совета директоров загрузчик Бытовая электроника Кросс-компилятор Встроенная база данных Встроенный гипервизор Встроенная ОС Встроенное программное обеспечение ПЛИС Интернет вещей Объем памяти Микроконтроллер Одноплатный компьютер Малиновый Пи SoC
Прошивка и управление	Прошивка Кастомная прошивка Фирменная прошивка Закрытая платформа Каленое ПО Дефект по дизайну Взлом бытовой электроники Доморощенный (видеоигры) джейлбрейк iOS Джейлбрейк PlayStation 3 Рутирование (Android) УЕФИ Привязка к поставщику
Загрузчики	U-Boot Barebox
Библиотеки программного обеспечения	uClibc диетическая библиотека Встроенный GLIBC lwIP мышца
Инструменты программирования	Оболочка Альмквиста BitBake Строитьрут Бизибокс OpenEmbedded Автономная оболочка Ящик для игрушек Йокто Проект
Операционные системы	Linux во встроенных системах Linux для мобильных устройств Легкий дистрибутив Linux Операционная система реального времени Windows Интернет вещей Победа CE
Языки программирования	Есть Язык ассемблера КАПЛ Встроенный C Встроенный С++ Встроенная Java МИСРА С МикроПитон
Легкие браузеры Список оборудования с открытым исходным кодом Робототехника с открытым исходным кодом