13

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?

Mogsdad
  • 44,709
  • 21
  • 151
  • 275
R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711

2 Answers2

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 …

SamB
  • 9,039
  • 5
  • 49
  • 56
0

The rationale for the behaviour of sched_setparam etc. in Linux is that threads are in fact processes created by the clone(2) system call, cf. glibc/nptl/sysdeps/pthread/createthread.c.

chill
  • 16,470
  • 2
  • 40
  • 44
  • 2
    "Threads are in fact processes" is an old saying that's not in fact true. Processes are what the kernel calls "thread groups", and they're quite distinct from threads. However, what you're saying was probably still "true" at the time these interfaces were added; the rationale for leaving them doing the wrong thing might just be existing application usage. However, giving that NPTL fixed most of the incorrect semantics from LinuxThreads, it seems odd that this issue was not fixed too... – R.. GitHub STOP HELPING ICE Nov 21 '12 at 14:34
  • OK, that wording does not sound good, indeed, although it's no less (or more) true now compared to the LinuxThreads times. Anyway, there's no distinct "thread group with a single thread" schedule-able entity in kernel and both `fork` and `pthread_create` reach to the same `do_fork` function in the kernel, which creates an instance of the same `struct task_struct`. – chill Nov 21 '12 at 15:17
  • 1
    I agree there's no scheduling properties for processes (thread groups) in Linux. That's why NPTL omits the process scheduling contention scope (which POSIX makes optional, by the way). What I don't get is why these functions are changing the scheduling properties of a single thread when they seem to be specified as near or complete no-ops. – R.. GitHub STOP HELPING ICE Nov 21 '12 at 15:20
  • As far as the kernel (or at least the `clone(2)` manpage) is concerned, a thread is really just a kind of process, and what POSIX calls a process is called a thread group. – SamB Jan 19 '14 at 04:41