Linux - threads and process scheduling priorities

Question

if we create pthreads (pthread_create) or processes (fork) with default scheduling policies on linux, will the scheduler treats the processes and threads with same priority

Answer 1

Linux no longer schedules processes at all.

Within the kernel, threads are scheduled. The concept of a process is now an artificial construct seen mostly by things outside the kernel. Obviously, the kernel has to know how threads are tied together, but not for scheduling purposes.

Basically, the kernel maintains a whole lot of threads and each thread has a thread group leader, which is what's seen on the outside as the process. A thread has a thread ID and a thread group ID - it's a lot like the relationship between a PID and a PPID (process ID and parent process ID).

When you create a regular thread, the kernel gives it a brand new thread ID but its thread group ID is set identical to the group ID of the thread that created it. That way, it looks like a thread within a process to the outside world.

When you fork, the kernel gives it a brand new thread ID and sets its thread group ID to the same value as its thread ID. That way, it looks like a process to the outside world.

Most non-kernel utilities that report on processes are really just reporting on threads where the thread ID is the same as the thread group ID.

There are subtleties with other methods which are probably too complicated to go into here. What I've written above is (hopefully) a good medium level treatise.

Now, for your specific question, it would be neither case since P1 only has one thread (there is no P1T2).

Withing the kernel, the threads are P1T1, P2T1 and P2T2 and, assuming they have the same scheduling properties and behave the same ^(a), that's how they'll be scheduled.

---

See also:

• Linux - Threads and Process;
• If I have a process, and I clone it, is the PID the same?; and
• Will a CPU process have at least one thread?

for more information.

---

^(a): Obviously that changes if the threads start blocking on I/O (kernel won't schedule them until I/O is available) or releasing their time quanta early (kernel will probably up their priority as a reward for playing nicely) but then they're not behaving the same.

Answer 2

It's true that Linux kernel (from version 2.6.23 and on) schedules tasks, which are either threads or (single-threaded) processes.

In addition to the accepted answer of paxdiablo, I am adding this one in order to add one more generic informative view about different ways of thread scheduling.

In general, threads can be either user-space threads or kernel-space threads. User-space threads are usually implemented by a library. Thus, kernel knows almost nothing about them (kernel knows only about the process they belong to) and they are handled in user-space. Contrariwise, kernel threads are implemented by kernel and they are completely handled by the kernel. You can take a generic view from the following image.

As you can see, the left picture show some user-space threads, where kernel possesses only information about processes (the so-called process control blocks - PCBs). All the resources-info regarding the threads are kept inside the process (in a thread table) and handled by the corresponding threads library in user space. In the right picture, you can see kernel threads, where both process table and threads table are kept in kernel.

An example of kernel threads are LinuxThreads, which have now been replaced by the more modern NPTL library. An example of user-space threads is the library GNU Portable Threads

Now, as far as scheduling is concerned, as it is expected, user-space threads are scheduled in a different way to kernel threads :

• When user-space threads are used, the scheduler is scheduling processes. So, it selects a specific process and allocates the allowable time quantum. Then, the thread scheduler inside the process is responsible to select how the scheduling between the threads will be made. Since user-space threads are not stopped by interrupts, the selected thread will tend to consume the whole quantum of the process, until it has completed its task. So, the hypothetical scheduling in this case would be something like:

  P1(T1), P2(T1), P1(T1), P2(T1 - T1 completes its task and yields), P2(T2 - for the remaining time quantum, P1(T1), P2(T2), P1(T1), ...

• When kernel threads are used, then kernel schedules threads. The kernel show no interest to which process the thread belongs, but it allocates one time quantum to each thread equally. So, in this case the hypothetical scheduling would be :

  P1(T1), P2(T1), P2(T2), P1(T1), P2(T2), P1(T1), ...

---

Note that there is also another category, the hybrid threads, where some user-space threads are translated into one kernel thread. However, it is more complex and requires a more thorough analysis.