Understanding discrepancy between POSIX and Linux/glibc sched_* functions

Question

POSIX XSH 2.8.4 Process Scheduling defines the behavior of scheduling attributes for threads and processes. The sched_* interfaces are specified to affect the scheduling properties of the process, not the thread. This is clarified in the following passages:

The POSIX model treats a "process" as an aggregation of system resources, including one or more threads that may be scheduled by the operating system on the processor(s) it controls. Although a process has its own set of scheduling attributes, these have an indirect effect (if any) on the scheduling behavior of individual threads as described below.

and

For threads with system scheduling contention scope, the process scheduling attributes shall have no effect on the scheduling attributes or behavior either of the thread or an underlying kernel scheduling entity dedicated to that thread.

My reading of this is that, on a system where only the "system scheduling contention scope" is supported (Linux/glibc is such a system), the sched_* functions should have absolutely no observable effect.

This is contrary to the reality of the current behavior on Linux/glibc where sched_* set the scheduling attributes of a particular thread.

Aside from wanting to better understand this situation in general, I guess I have these key questions:

1. Is there any documentation of the rationale for this discrepancy?

2. Is my reading of the standard correct? In particular, it seems really surprising to me that sched_setparam and sched_setscheduler would be specified to have no effect in a single-threaded application (where the main thread is using the default scheduling policy, which cannot be changed, and system contention scope).

3. What is the usefulness of standard's sched_* functions? It seems to me they have no effect on most implementations, and minimal effect even on implementations that support the process contention scope. Could somebody describe the intended usage of them?

Answer 1

I believe the reason is that it has been this way since before NPTL was implemented, and nobody has contributed thread-group-wide scheduling attribute support to the kernel, so these functions just still do the what they have always done.

And possibly because, as you point out, the way POSIX specifies them would not really be at all useful without process contention scope …