Понимание несоответствия между функциями POSIX и Linux/glibc sched_ *

POSIX XSH 2.8.4 Планирование процесса определяет поведение атрибутов планирования для потоков и процессов. Интерфейсы sched_* указаны, чтобы повлиять на свойства планирования процесса, а не на поток. Это разъясняется в следующих отрывках:

Модель POSIX рассматривает "процесс" как совокупность системных ресурсов, включая один или несколько потоков, которые могут быть запланированы операционной системой на процессоре (процессорах), которые он контролирует. Хотя процесс имеет свой собственный набор атрибутов планирования, они имеют косвенный эффект (если он есть) на поведение планирования отдельных потоков, как описано ниже.

и

Для потоков с областью конкуренции с планированием системы атрибуты планирования процесса не должны влиять на атрибуты планирования или поведение ни потока, ни основного объекта планирования ядра, выделенного для этого потока.

Мое прочтение этого состоит в том, что в системе, где поддерживается только "область разрешения системного планирования" (Linux/glibc - такая система), функции sched_* не должны иметь абсолютно никакого наблюдаемого эффекта.

Это противоречит реальности текущего поведения в Linux/glibc, где sched_* задает атрибуты планирования для определенного потока.

Помимо желающих лучше понять эту ситуацию в целом, я думаю, у меня есть следующие ключевые вопросы:

Есть ли какая-либо документация об обосновании этого несоответствия?
Я правильно ли читаю стандарт? В частности, мне кажется удивительно, что sched_setparam и sched_setscheduler будут указаны как не имеющие эффекта в однопоточном приложении (где основной поток использует политику планирования по умолчанию, которая не может быть изменена, и системное соперничество сфера применения).
Какова полезность стандартных функций sched_*? Мне кажется, что они не влияют на большинство реализаций и минимальный эффект даже на реализации, которые поддерживают сферу конкуренции процесса. Может ли кто-нибудь описать предполагаемое использование их?

Ответ 1

Я полагаю, что причина в том, что так было до того, как NPTL был реализован, и никто не предоставил поддержку атрибутов атрибутов нитей для всей группы ядра, поэтому эти функции просто выполняют то, что они всегда делали.

И, возможно, потому, что, как вы указываете, способ, которым POSIX указывает их, на самом деле не был бы действительно полезен без области рассмотрения процесса & hellip;

Ответ 2

Обоснование поведения sched_setparam и т.д. в Linux заключается в том, что потоки фактически являются процессами, созданными системным вызовом clone(2), ср. glibc/nptl/sysdeps/pthread/createthread.c.