Операционная система реального времени - Real-time operating system

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

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

Ключевой характеристикой ОСРВ является уровень ее согласованности в отношении количества времени, необходимого для принятия и выполнения приложения. задача; изменчивость 'дрожь '.[1] «Жесткая» операционная система реального времени (Hard RTOS) имеет меньший джиттер, чем «мягкая» операционная система реального времени (Soft RTOS). Поздний ответ - это неправильный ответ в жесткой RTOS, в то время как поздний ответ приемлем в мягкой RTOS. Основная цель дизайна невысока пропускная способность, а скорее гарантия мягкий или жесткий категория исполнения. ОСРВ, которая обычно или обычно может уложиться в срок, является ОС реального времени, но если она может уложиться в срок детерминированно это ОС реального времени.[2]

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

Увидеть сравнение операционных систем реального времени для полного списка. Также см. список операционных систем для всех типов операционных систем.

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

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

Самые распространенные конструкции:

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

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

Рано Проекты ЦП требовалось много циклов для переключения задач, в течение которых ЦП не мог делать ничего полезного. Например, с частотой 20 МГц 68000 процессора (типично для конца 1980-х годов) время переключения задач составляет примерно 20 микросекунд. Напротив, 100 МГц РУКА Процессор (с 2008 г.) переключается менее чем за 3 микросекунды.[4][5] Поскольку переключение занимало очень много времени, ранние операционные системы пытались минимизировать потери процессорного времени, избегая ненужного переключения задач.

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

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

  1. Выполняется (выполняется на ЦП);
  2. Готов (готов к исполнению);
  3. Заблокирован (ожидание события, например ввод-вывод).

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

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

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

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

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

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

Алгоритмы

Некоторые часто используемые алгоритмы планирования RTOS:

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

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

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

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

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

Мьютексы

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

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

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

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

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

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

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

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

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

Точно так же Режим управления системой на оборудовании, совместимом с x86, может пройти слишком много времени, прежде чем оно вернет управление операционной системе. Как правило, неправильно писать программы реального времени для оборудования x86.[нужна цитата ]

Выделение памяти

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

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

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

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

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

Смотрите также

Рекомендации

  1. ^ «Время отклика и джиттер».
  2. ^ Таненбаум, Эндрю (2008). Современные операционные системы. Река Аппер Сэдл, штат Нью-Джерси: Пирсон / Прентис-Холл. п. 160. ISBN  978-0-13-600663-3.
  3. ^ «Концепции RTOS».
  4. ^ «Время переключения контекста». Системы микроконтроллеров Segger. Получено 2009-12-20.
  5. ^ «Сравнение производительности ОСРВ на emb4fun.de». Архивировано из оригинал на 2013-01-11.
  6. ^ Франер, Ральф А. (осень 1984 г.). «Будущее Unix на IBM PC». БАЙТ. С. 59–64.
  7. ^ CS 241, Университет Иллинойса