Ю. Вахалия - UNIX изнутри (2003) (1114670), страница 49

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 49)

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

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

Время реакции является суммой времени, требуемого для обработки события обработчиком, времени задержки обслуживания планировшиком и времени, необходимого для проведения обработки события самим процессом реального времени. Величина задержки обслуживания планировщиком во многом зависит от ядра. Ядра традиционных систем не в состоянии обеспечить приемлемых границ этой задержки, так как они являются невытесняющими, вследствие чего готовый к выполнению процесс класса реального времени может ждать довольно долго, если текущий процесс «застрянет» в некоторой 5.5. Планировщик в системе ВЧЙ4 209 замысловатой процедуре ядра.

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

Время реакции и задержки обслуживания планировщиком В системе 3Ъ'К4 для разделения длинных алгоритмов ядра на более короткие и ограниченные блоки выполнения применяются точки вытеснения. Когда процесс реального времени становится готовым к выполнению, процедура й ига)гецр(), которая обрабатывает классо-зависимую часть процедуры пробуждения, устанавливает определенный в ядре флаг 1ргцлгцл. Когда текущий процесс (предположительно выполняющийся в режиме ядра) достигает точки вытеснения, ядро проверяет флаг и инициирует переключение контекста для процесса реального времени.

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

Если в течение любого периода своего ожидания высокоприоритетный процесс становится готовым к выполнению, то он будет назначен на выполнение в первую очередь. После того как процесс получит процессор в свое распоряжение, пересчет задержки начнется с нуля. 5.5.5. Системный вызов рг1осгй! Системный вызов рпослтг предлагает ряд возможностей для управления приоритетами и планированием процесса. Для него определен набор подкоманд, которые могут быть использованы для различных операций, таких как: + изменение приоритета класса процесса; + установка значения тз црп' для процессов класса разделения времени; 210 Глава 5. Планирование процессов + сброс в значение по умолчанию приоритета и кванта времени для процесса реального времени; + получение текущего значения ряда параметров планирования. Большинство из этих операций можетп производить только суперпользователь, следовательно, они недоступны большинству приложений.

В системе ЯЪ'К4 также имеется системный вызов рпосп~Ьег, производящий те же операции, но над набором связанных чем-либо процессов, например: + всех процессов системы; + всех процессов группы или сеанса; + всех процессов в определенном классе планирования; + всех процессов, принадлежащих определенному пользователю; + всех процессов, имеющих одного и того же родителя. 5.5.6.

Анализ В системе БУК4 традиционный планировщик был заменен новым планировщиком, отличным по устройству и по принципам работы. Новый планировщик обеспечивает гибкий подход, позволяющий добавлять новые классы планирования в систему. Производители программного обеспечения получили возможность «скроить» свой планировщик, который бы удовлетворял их приложениям. Применение таблиц параметров диспетчера расширило возможности системного администратора, поскольку появилась способность контролировать поведение системы путем изменения табличных установок и последующей пересборки ядра. В традиционных системах ПЫ1Х пересчет приоритетов процессов ведется каждую секунду.

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

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

Планировщик в системе Зчй4 211 му связанные с собьггиями операции по оптимальному повышению или понижению приоритетов зависят от общей загруженности системы и характеристик задач, работающих в текущий момент времени. Таким образом, для повышения эффективности системы и скорости реакции эти величины могут часто перенастраиваться. Добавление какого-либо класса планирования не требует доступа к исходным кодам ядра. Для этой цели разработчик должен произвести следующие последовательные действия.

1. Разработать реализацию каждой классо-зависимой функции нового класса планирования. 2. Инициализировать вектор с1аЫапсэ указателями на эти функции. 3. Разработать функцию инициализации, выполняющую различные действия (например, выделить память для внутренних структур данных и т. д.) при установке нового класса. 4. Добавить запись для этого класса в таблицу классов в основном файле конфигурации, находящемся обычно в подкаталоге шаз1еп4 каталога сборки ядра.

Эта запись должна содержать указатели на функцию инициализации и на вектор с1азэЬпсэ. 5. Произвести пересборку ядра. Существенным ограничением является то, что в системе БЧК4 не обеспечено сколько-нибудь приемлемого способа для перевода процессов класса разделения времени в иной класс. Вызов рпосп11 может быть в распоряжении только суперпользователя. Был бы очень полезен механизм, который умел бы отображать определенные идентификаторы пользователей или программы в класс, отличный от принятого по умолчанию. Несмотря на то что средства поддержки класса реального времени явились важным шагом, они оказались далеки до соответствия желаемым возможностям.

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

Некоторые из этих аспектов были реализованы в системе Бо!аПэ 2.х, в которой были расширены возможности планировщика ЯЧК4. Мы расскажем о них в следующем разделе главы. Основной проблемой планировщика БЧК4 является чрезвычайная сложность более-менее качественной настройки системы при работе со смешанными наборами приложений. В книге 113~ описывается эксперимент, при котором в системе одновременно запускались три различных приложения: интерактивный сеанс с клавиатурным вводом данных, пакетное задание и программа для просмотра видео.

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

Список файлов книги