диспетчер в режиме реального времени операционной системы
Я читаю о концепциях реального времени по следующей ссылке
http://www.embeddedlinux.org.cn/RTConforEmbSys/5107final/LiB0024.html
Здесь в разделе 4.4.4 упоминается
Диспетчер является частью планировщика, который выполняет контекст
переключение и изменение потока исполнения. В любое время RTOS
работает, поток выполнения, также известный как поток управления, является
проходя через одну из трех областей: через прикладную задачу,
через ISR или через ядро. Когда задача или ISR делает
системный вызов, поток управления переходит к ядру для выполнения одного
системных подпрограмм, предоставляемых ядром. Когда пришло время
покиньте ядро, диспетчер отвечает за прохождение контроля
к одной из задач в приложении пользователя. Это не обязательно
быть той же задачей, которая сделала системный вызов.Это алгоритмы планирования (будут обсуждаться в ближайшее время)
планировщик, который определяет, какая задача будет выполняться дальше. Это
диспетчер, который выполняет фактическую работу по переключению и передаче контекста
контроль исполнения.В зависимости от того, как ядро вводится впервые, диспетчеризация может произойти
по-другому. Когда задача выполняет системные вызовы, диспетчер используется для
выйдите из ядра после завершения каждого системного вызова. В этом случае
диспетчер используется для каждого вызова, чтобы он мог координировать
переходы состояния задачи, которые могут иметь любые системные вызовы
вызвало. (Например, одна или несколько задач могут быть готовы к запуску.)С другой стороны, если ISR выполняет системные вызовы, диспетчер
обойден, пока ISR полностью не завершит свое выполнение. Этот процесс
истина, даже если некоторые ресурсы были освобождены, что обычно
вызвать переключение контекста между задачами. Эти переключатели контекста не
происходит, потому что ISR должен завершиться без прерывания
задачи. После того, как ISR завершает выполнение, ядро выходит через
диспетчер, чтобы он мог затем отправить правильное задание
.
Мой вопрос по тексту выше
- Что подразумевается под автором: «Когда задача выполняет системные вызовы, диспетчер используется для выхода из ядра
после завершения каждого системного вызова. В этом случае диспетчер используется для каждого вызова, чтобы он мог координировать переходы состояния задачи, которые любой из
системные вызовы могли быть вызваны. «В частности, здесь то, что автор подразумевает под диспетчером, используется для выхода из ядра.
Спасибо!
Решение
Автор представляет упрощенное объяснение архитектуры системы в реальном времени, где поток управления может находиться в одном из трех состояний — режиме ядра (системные вызовы), режиме приложения (TASK) или режиме подпрограммы обработки прерываний (ISR).
диспетчер в этом примере — подпрограмма ядра, которая решает ЗАДАЧУ приложения, которая должна получить управление после завершения каждого системного вызова, сделанного одной из ЗАДАЧ приложения. Это может быть ЗАДАЧА, которая выдала системный вызов, или это может быть другая ЗАДАЧА в зависимости от алгоритмов и правил диспетчеризации, которые соблюдаются.
Существует много вариантов правил и алгоритмов диспетчеризации, основанных на планируемом использовании системы; В качестве примера вы могли бы подумать о предоставлении каждой ЗАДАЧЕ равного количества процессорного времени в минуту — поэтому, если выполняются 3 ЗАДАЧИ приложения, каждое из них должно получать 20 секунд процессорного времени каждую минуту. Диспетчер в этом случае может решить, что следующей задачей TASK для получения управления будет TASK с наименьшим накопленным временем ЦП за последнюю минуту, чтобы попытаться равномерно распределить время ЦП в минуту между заданиями.
После принятия решения о том, какой из TASK должен получить следующий элемент управления, диспетчер выйдет из режима системного вызова и передаст управление приложению TASK, поэтому вызов диспетчера эквивалентен «выходу» из ядра и передаче управления подходящему приложению TASK.
Автор заявляет, что это система реального времени, что означает, что упор будет сделан на быструю обработку прерываний (через ISR) над обработкой приложений (ЗАДАЧИ). Чтобы свести к минимуму количество времени, затрачиваемое каждым прерыванием, когда ISR выполняет системный вызов, ядро будет напрямую возвращаться к этому ISR, а не «выход через диспетчер», который позволил бы контролировать управление приложением TASK.
Когда ISR завершит свою обработку, его выход будет выполнен таким образом, что ядро вызовет диспетчер (следовательно, он выйдет через диспетчер), так что ЗАДАЧА приложения сможет снова использовать ЦП.
В качестве дополнительного примечания: одно из скрытых предположений в этом объяснении состоит в том, что те же подпрограммы ядра (системные вызовы) могут вызываться ЗАДАЧАМИ приложения и подпрограммами обработки прерываний (ISR). Это очень часто, но проблемы безопасности и производительности могут потребовать разных наборов подпрограмм ядра (системных вызовов) для ISR и ЗАДАЧ.
Другие решения
После завершения системного вызова выполнение должно быть передано обратно в задачу пространства пользователя. Вероятно, есть много задач в пространстве пользователя, ожидающих запуска, и у всех них могут быть разные приоритеты. Диспетчер использует свой алгоритм для оценки задач ожидания на основе приоритета и других критериев (как долго они ждали? Как долго я ожидаю, что они нужны?), А затем запускает одну из них.
Например, у вас может быть приложение, которое должно читать ввод из командной строки. Таким образом, ваше приложение вызывает системный вызов read (), который передает управление ядру. После завершения read () диспетчер оценивает задачи, ожидающие выполнения, и может решить, что должна быть запущена другая задача, кроме той, которая вызвала read ()