Читаем Linux API. Исчерпывающее руководство полностью

• Приложение реального времени должно иметь возможность контролировать порядок, в котором выполняются его отдельные процессы.

Стандарт SUSv3 описывает программный интерфейс для планирования процессов в режиме реального времени (изначально входил в POSIX.1b), который частично отвечает описанным выше требованиям. Этот интерфейс предоставляет две политики планирования: SCHED_RR и SCHED_FIFO. Процессы, работающие в их рамках, всегда имеют приоритет перед процессами, планируемыми в соответствии с алгоритмом циклического разделения времени, описанного в разделе 35.1 (определяется константой SCHED_OTHER).

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

Утверждение о том, что процесс с повышенным приоритетом всегда обгоняет менее приоритетные процессы, относится к многопроцессорным (в том числе и гиперпоточным) Linux-системам. Каждый процессор в таких системах имеет свою отдельную очередь выполнения (что обеспечивает лучшую производительность по сравнению с единой системной очередью), в рамках которой и расставляются приоритеты. Представьте, что на двухпроцессорном компьютере выполняется три процесса; процесс А с приоритетом реального времени 20 может попасть в очередь ожидания процессора 0, который в этот момент выполняет процесс Б с приоритетом 30, хотя в то же самое время на процессоре 1 работает процесс В с приоритетом 10.

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

Linux предоставляет 99 приоритетов реального времени: от 1 (низшего) до 99 (высшего); этот диапазон распространяется на обе политики планирования (SCHED_RR и SCHED_FIFO). Приоритеты в каждой из политик являются эквивалентными. Это означает, что любой из двух процессов с одинаковыми приоритетами, но разными политиками может в одинаковой степени претендовать на получение процессорного времени, в зависимости от порядка, в котором они были запланированы. В сущности, каждый приоритет хранит очередь выполняющихся процессов, и процесс, который будет выполнен следующим, берется из начала (непустой) очереди с самым высоким приоритетом.

Жесткий режим реального времени по сравнению с режимом POSIX

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

Добавление поддержки жесткого режима реального времени сложно достичь без затраты дополнительных ресурсов; это не позволило бы достичь производительности, необходимой для приложений, планируемых по алгоритму разделения времени (коих большинство как в настольных, так и в серверных системах). Именно поэтому большинство ядер в UNIX-системах, включая Linux, изначально не имели стандартной поддержки приложений реального времени. Тем не менее, начиная с версии 2.6.18, в ядре Linux стали появляться возможности, которые в конечном счете должны обеспечить полную поддержку жесткого режима реального времени без вышеупомянутой затраты ресурсов для операций разделения времени.

35.2.1. Политика SCHED_RR

В рамках политики SCHED_RR (циклического разделения) процессы с одинаковым приоритетом выполняются в соответствии с циклическим разделением времени. При каждом использовании ЦПУ процесс получает квант времени фиксированной длины и выполняется до тех пор, пока он не:

• достигнет конца своего временного отрезка;

• добровольно освободит ресурсы процессора — либо выполнив блокирующую системную операцию, либо сделав вызов sched_yield() (описанный в подразделе 35.3.3);

• завершится;

• будет вытеснен процессом с более высоким приоритетом.