Блог

Я читаю о концепциях реального времени по следующей ссылке

http://www.embeddedlinux.org.cn/RTConforEmbSys/5107final/LiB0024.html

Здесь, в разделе 4.4.4, упоминается, что

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

Именно алгоритмы планирования (которые будут рассмотрены вкратце) планировщика определяют, какая задача выполняется следующей. Именно диспетчер выполняет фактическую работу по переключению контекста и передаче управления выполнением.

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

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

.

Мой вопрос по приведенному выше тексту

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

Спасибо!

Автор представляет упрощенное объяснение архитектуры системы реального времени, в которой поток управления может находиться в одном из трех состояний — режиме ядра (системные вызовы), режиме приложения (ЗАДАЧА) или режиме процедуры обслуживания прерываний (ISR).

Диспетчер в этом примере представляет собой подпрограмму ядра, которая решает прикладную ЗАДАЧУ, которая должна получать управление после завершения каждого системного вызова, выполняемого одной из прикладных задач. Это может быть ЗАДАЧА, которая вызвала системный вызов, или это может быть другая ЗАДАЧА, в зависимости от алгоритмов диспетчеризации и правил, которые выполняются.

Существует множество вариантов правил и алгоритмов диспетчеризации, основанных на планируемом использовании системы; В качестве примера вы можете подумать о предоставлении каждой ЗАДАЧЕ равного количества процессорного времени в минуту — поэтому, если выполняются 3 прикладные ЗАДАЧИ, каждая из которых должна получать 20 секунд процессорного времени каждую минуту. Диспетчер в этом случае может решить, что следующая ЗАДАЧА для получения управления — это ЗАДАЧА с наименьшим накопленным процессорным временем за последнюю минуту в попытке равномерно распределить процессорное время в минуту между ЗАДАЧАМИ.

После принятия решения о том, какая ЗАДАЧА должна получить управление следующей, диспетчер выйдет из режима системного вызова и передаст управление ЗАДАЧЕ приложения, поэтому вызов диспетчера эквивалентен «выходу» из ядра и передаче управления соответствующей ЗАДАЧЕ приложения.

Автор утверждает, что это система реального времени, что означает, что акцент будет сделан на быструю обработку прерываний (через ISR) над обработкой приложений (ЗАДАЧ). Чтобы минимизировать количество времени, затрачиваемого на каждое прерывание, когда ISR выдает системный вызов, ядро будет напрямую возвращаться к этому ISR, а не «выходить через диспетчера», что позволило бы передать управление прикладной задаче.

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

В качестве дополнительного примечания: одно из скрытых предположений в этом объяснении заключается в том, что одни и те же подпрограммы ядра (системные вызовы) могут вызываться прикладными ЗАДАЧАМИ и подпрограммами обслуживания прерываний (ISR). Это очень распространенное явление, но проблемы с безопасностью и производительностью могут потребовать разных наборов подпрограмм ядра (системных вызовов) для ISR и ЗАДАЧ.

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

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