• Приложение реального времени должно иметь возможность контролировать порядок, в котором выполняются его отдельные процессы.
Стандарт 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). Приоритеты в каждой из политик являются эквивалентными. Это означает, что любой из двух процессов с одинаковыми приоритетами, но разными политиками может в одинаковой степени претендовать на получение процессорного времени, в зависимости от порядка, в котором они были запланированы. В сущности, каждый приоритет хранит очередь выполняющихся процессов, и процесс, который будет выполнен следующим, берется из начала (непустой) очереди с самым высоким приоритетом.
Режим реального времени, который удовлетворяет всем требованиям, перечисленным в начале этого раздела, иногда называют
Добавление поддержки жесткого режима реального времени сложно достичь без затраты дополнительных ресурсов; это не позволило бы достичь производительности, необходимой для приложений, планируемых по алгоритму разделения времени (коих большинство как в настольных, так и в серверных системах). Именно поэтому большинство ядер в UNIX-системах, включая Linux, изначально не имели стандартной поддержки приложений реального времени. Тем не менее, начиная с версии 2.6.18, в ядре Linux стали появляться возможности, которые в конечном счете должны обеспечить полную поддержку жесткого режима реального времени без вышеупомянутой затраты ресурсов для операций разделения времени.
35.2.1. Политика SCHED_RR
В рамках политики SCHED_RR (циклического разделения) процессы с одинаковым приоритетом выполняются в соответствии с циклическим разделением времени. При каждом использовании ЦПУ процесс получает квант времени фиксированной длины и выполняется до тех пор, пока он не:
• достигнет конца своего временного отрезка;
• добровольно освободит ресурсы процессора — либо выполнив блокирующую системную операцию, либо сделав вызов sched_yield() (описанный в подразделе 35.3.3);
• завершится;
• будет вытеснен процессом с более высоким приоритетом.
