Войти
A Операционная система реального времени (RTOS ) - это операционная система (ОС) предназначена для обслуживания приложений реального времени, которые обрабатывают данные по мере их поступления, обычно без задержек buffer. Требования ко времени обработки (включая любую задержку ОС) измеряются десятыми долями секунды или более короткими интервалами времени. Система реального времени - это система, привязанная ко времени, которая имеет четко определенные фиксированные временные ограничения. Обработка должна выполняться в рамках определенных ограничений, иначе система выйдет из строя. Они либо , управляемые событиями, либо с разделением времени. Системы, управляемые событиями, переключаются между задачами на основе их приоритетов, в то время как системы с разделением времени переключают задачи на основе прерываний часов . Большинство ОСРВ используют алгоритм упреждающего планирования.
Ключевой характеристикой RTOS является уровень его согласованность в отношении количества времени, необходимого для принятия и выполнения задачи приложения; изменчивость составляет «дрожание ». «Жесткая» операционная система реального времени (Hard RTOS) имеет меньший джиттер, чем «мягкая» операционная система реального времени (Soft RTOS). Поздний ответ - это неправильный ответ в жесткой ОСРВ, в то время как поздний ответ приемлем в мягкой ОСРВ. Главная цель проектирования - не высокая пропускная способность, а скорее гарантия категории мягких или жестких характеристик. ОСРВ, которая обычно или обычно может уложиться в срок, является ОС реального времени, но если она может уложиться в срок детерминированно, то это ОС жесткого реального времени.
ОСРВ имеет расширенный алгоритм для планирования. Гибкость планировщика обеспечивает более широкую оркестровку компьютерной системы приоритетов процессов, но ОС реального времени чаще предназначена для узкого набора приложений. Ключевыми факторами в ОС реального времени являются минимальная задержка прерывания и минимальная задержка переключения потоков ; ОС реального времени ценится больше за то, насколько быстро или предсказуемо она может реагировать, чем за объем работы, которую она может выполнить за определенный период времени.
См. сравнение операций в реальном времени systems для получения полного списка. Также см. список операционных систем для всех типов операционных систем.
ОСРВ - это операционная система, в которой время, затрачиваемое на обработку входного стимула, меньше времени, прошедшего до следующего входного стимула того же типа.
Наиболее распространенные конструкции:
с разделением времени, проекты переключают задачи чаще, чем это необходимо, но обеспечивают более плавную многозадачность, создавая иллюзию, что процесс или пользователь единолично использует машину.
Ранние конструкции ЦП требовали много циклов для переключения задач, в течение которых ЦП не мог делать больше ничего полезного. Например, для процессора 20 МГц 68000 (типично для конца 1980-х годов) время переключения задач составляет примерно 20 микросекунд. Напротив, процессор ARM 100 МГц (с 2008 г.) переключается менее чем за 3 микросекунды. Поскольку переключение занимало очень много времени, ранние операционные системы пытались свести к минимуму потери процессорного времени, избегая ненужного переключения задач.
В типичных проектах задача имеет три состояния:
Большинство задач заблокированы или готовы большую часть времени, потому что обычно только одна задача может выполняться одновременно на ЦП. Количество элементов в очереди готовности может сильно различаться в зависимости от количества задач, которые система должна выполнить, и типа планировщика, который система использует. В более простых, не вытесняющих, но по-прежнему многозадачных системах задача должна отдавать свое время ЦП другим задачам, что может привести к тому, что очередь готовности будет иметь большее количество общих задач в состоянии готовности к выполнению (ресурсный голод ).
Обычно структура данных списка готовности в планировщике предназначена для минимизации наихудшего времени, затрачиваемого в критической секции планировщика, в течение которого запрещается приоритетное прерывание, и, в некоторых случаях, все прерывания отключены, но выбор структуры данных зависит также от максимального количества задач, которые могут быть в списке готовности.
Если в готовом списке никогда не более нескольких задач, то двусвязный список готовых задач, вероятно, будет оптимальным. Если в готовом списке обычно всего несколько задач, но иногда и больше, то список следует отсортировать по приоритету. Таким образом, поиск задачи с наивысшим приоритетом для выполнения не требует итерации по всему списку. Затем для вставки задачи необходимо пройти по списку готовности до тех пор, пока не будет достигнут конец списка или задача с более низким приоритетом, чем у вставляемой задачи.
Следует проявлять осторожность, чтобы не препятствовать вытеснению во время этого поиска. Более длинные критические секции следует разделять на небольшие части. Если происходит прерывание, которое делает задачу с высоким приоритетом готовой во время вставки задачи с низким приоритетом, эта задача с высоким приоритетом может быть вставлена и запущена непосредственно перед вставкой задачи с низким приоритетом.
Критическое время отклика, иногда называемое временем обратного хода, - это время, необходимое для постановки новой готовой задачи в очередь и восстановления состояния выполнения задачи с наивысшим приоритетом. В хорошо спроектированной ОСРВ для подготовки новой задачи потребуется от 3 до 20 инструкций на каждую запись очереди готовности, а для восстановления задачи готовности с наивысшим приоритетом потребуется от 5 до 30 инструкций.
В более продвинутых системах задачи реального времени совместно используют вычислительные ресурсы со многими задачами, не относящимися к реальному времени, и список готовности может быть сколь угодно длинным. В таких системах список готовых планировщиков, реализованный как связанный список, будет неадекватным.
Некоторые часто используемые алгоритмы планирования RTOS:
Многозадачная операционная система, такая как Unix, плохо справляется с задачами в реальном времени. Планировщик отдает наивысший приоритет заданиям с наименьшей нагрузкой на компьютер, поэтому невозможно гарантировать, что для критичного по времени задания будет доступ к достаточному количеству ресурсов. Системы многозадачности должны управлять совместным использованием данных и аппаратных ресурсов между несколькими задачами. Обычно для двух задач небезопасно обращаться к одним и тем же конкретным данным или аппаратному ресурсу одновременно. Существует три общих подхода к решению этой проблемы:
Операционные системы общего назначения обычно не позволяют пользовательским программам маскировать (отключать) прерывания, потому что программа пользователя может управлять процессором столько, сколько пожелает. Некоторые современные процессоры не позволяют коду пользовательского режима отключать прерывания, поскольку такое управление считается ключевым ресурсом операционной системы. Однако многие встроенные системы и ОСРВ позволяют самому приложению работать в режиме ядра для большей эффективности системного вызова, а также для того, чтобы приложение могло лучше контролировать операционную среду, не требуя Вмешательство ОС.
В однопроцессорных системах приложение, работающее в режиме ядра, и маскирование прерываний - это метод с наименьшими издержками для предотвращения одновременного доступа к общему ресурсу. Хотя прерывания замаскированы, и текущая задача не выполняет блокирующий вызов ОС, текущая задача имеет исключительное использование ЦП, поскольку никакая другая задача или прерывание не может взять на себя управление, поэтому критическая секция защищена. Когда задача выходит из критического раздела, она должна демаскировать прерывания; ожидающие прерывания, если таковые имеются, будут выполнены. Временное маскирование прерываний следует выполнять только в том случае, если самый длинный путь через критический участок короче желаемого максимального задержки прерывания. Обычно этот метод защиты используется только тогда, когда критическая секция состоит всего из нескольких инструкций и не содержит циклов. Этот метод идеально подходит для защиты аппаратных битовых регистров, когда биты управляются различными задачами.
Когда общий ресурс должен быть зарезервирован, не блокируя все другие задачи (например, ожидание записи во флэш-память), лучше использовать механизмы, также доступные при работе общего назначения. системы, такие как мьютекс и межпроцессный обмен сообщениями под контролем ОС. Такие механизмы включают в себя системные вызовы и обычно вызывают код диспетчера ОС при выходе, поэтому для их выполнения обычно требуются сотни инструкций ЦП, в то время как маскирование прерываний может занимать всего одну инструкцию на некоторых процессорах.
(нерекурсивный) мьютекс либо заблокирован, либо разблокирован. Когда задача заблокировала мьютекс, все другие задачи должны ждать, пока мьютекс не будет разблокирован его владельцем - исходным потоком. Задача может установить тайм-аут на ожидание мьютекса. Существует несколько хорошо известных проблем с схемами на основе мьютексов, таких как инверсия приоритета и взаимоблокировки.
. В инверсии приоритета высокоприоритетная задача ожидает, потому что задача с низким приоритетом имеет mutex, но задача с более низким приоритетом не получает процессорного времени для завершения своей работы. Типичное решение - иметь задачу, владеющую мьютексом, с приоритетом самой высокой ожидающей задачи или «наследовать» ее. Но этот простой подход становится более сложным, когда существует несколько уровней ожидания: задача A ожидает мьютекса, заблокированного задачей B, которая ожидает мьютекса, заблокированного задачей C. Обработка нескольких уровней наследования заставляет другой код запускаться в контексте с высоким приоритетом и, таким образом, может вызвать нехватку потоков со средним приоритетом.
В взаимоблокировке две или более задач блокируют мьютекс без тайм-аутов, а затем бесконечно ждут мьютекса другой задачи, создавая циклическую зависимость. Самый простой сценарий взаимоблокировки возникает, когда две задачи поочередно блокируют два мьютекса, но в обратном порядке. Тупиковая ситуация предотвращается благодаря тщательному проектированию.
Другой подход к совместному использованию ресурсов заключается в том, что задачи отправляют сообщения по организованной схеме передачи сообщений. В этой парадигме ресурсом напрямую управляет только одна задача. Когда другая задача хочет опросить ресурс или манипулировать им, она отправляет сообщение управляющей задаче. Хотя их поведение в реальном времени менее чётко, чем системы семафоров, простые системы на основе сообщений избегают большинства опасностей тупиковых ситуаций протокола и, как правило, ведут себя лучше, чем системы семафоров. Однако возможны проблемы, подобные проблемам семафоров. Инверсия приоритета может происходить, когда задача работает с сообщением с низким приоритетом и игнорирует сообщение с более высоким приоритетом (или сообщение, исходящее косвенно от задачи с высоким приоритетом) в своей очереди входящих сообщений. Взаимоблокировки протокола могут возникать, когда две или более задач ждут друг от друга отправки ответных сообщений.
Поскольку обработчик прерываний блокирует выполнение задачи с наивысшим приоритетом, а операционные системы реального времени предназначены для минимизации задержки потока, обработчики прерываний обычно сохранены как можно короче. Обработчик прерывания откладывает все взаимодействия с оборудованием, если это возможно; обычно все, что необходимо, - это подтвердить или отключить прерывание (чтобы оно больше не повторялось при возврате обработчика прерывания) и уведомить задачу о том, что работа должна быть выполнена. Это можно сделать, разблокировав задачу драйвера, выпустив семафор, установив флаг или отправив сообщение. Планировщик часто предоставляет возможность разблокировать задачу из контекста обработчика прерывания.
ОС поддерживает каталоги объектов, которыми она управляет, таких как потоки, мьютексы, память и т. Д. Обновления этого каталога должны строго контролироваться. По этой причине может возникнуть проблема, когда обработчик прерывания вызывает функцию ОС, в то время как приложение также выполняет это. Функция ОС, вызываемая из обработчика прерывания, могла обнаружить, что база данных объектов находится в несогласованном состоянии из-за обновления приложения. Есть два основных подхода к решению этой проблемы: унифицированная архитектура и сегментированная архитектура. ОСРВ, реализующие унифицированную архитектуру, решают проблему, просто отключая прерывания во время обновления внутреннего каталога. Обратной стороной этого является то, что увеличивается задержка прерывания, потенциально теряя прерывания. Сегментированная архитектура не делает прямых вызовов ОС, но делегирует работу, связанную с ОС, отдельному обработчику. Этот обработчик работает с более высоким приоритетом, чем любой поток, но ниже, чем обработчики прерываний. Преимущество этой архитектуры состоит в том, что она добавляет очень мало циклов для задержки прерывания. В результате ОС, реализующие сегментированную архитектуру, более предсказуемы и могут работать с более высокой частотой прерываний по сравнению с унифицированной архитектурой.
Аналогичным образом Режим управления системой на оборудовании, совместимом с x86, может работать слишком много времени, прежде чем он вернет управление операционной системе. Как правило, неправильно писать программное обеспечение реального времени для оборудования x86.
Выделение памяти более важно в операционной системе реального времени, чем в других операционных системах.
Во-первых, для стабильности не может быть утечек памяти (память, которая выделяется, но не освобождается после использования). Устройство должно работать бесконечно, без перезагрузки. По этой причине использование динамического распределения памяти не одобряется. По возможности, все необходимое распределение памяти указывается статически во время компиляции.
Еще одна причина избегать динамического распределения памяти - это фрагментация памяти. При частом выделении и освобождении небольших фрагментов памяти может возникнуть ситуация, когда доступная память разделена на несколько разделов и ОСРВ неспособна выделить достаточно большой непрерывный блок памяти, хотя свободной памяти достаточно. Во-вторых, важна скорость выделения. Стандартная схема распределения памяти сканирует связанный список неопределенной длины, чтобы найти подходящий свободный блок памяти, что недопустимо в RTOS, поскольку выделение памяти должно происходить в течение определенного промежутка времени.
Поскольку механические диски имеют гораздо более длительное и непредсказуемое время отклика, переключение на дисковые файлы не используется по тем же причинам, что и выделение RAM, описанное выше.
Простой алгоритм блоков фиксированного размера работает достаточно хорошо для простых встроенных систем из-за его низких накладных расходов.
 | Викибук Встроенные системы имеет страницу на тему: Операционные системы реального времени |
