I'm wondering about the "punishment" that occurs when a new thread is created.

From my understanding of clone(2), NPTL (New POSIX Thread Library), CFS (Completely Fair Scheduler), when a new thread is created it is seen as a new process because NPTL uses a 1:1 thread model.

From what I've read about the scheduler, when a new process is added to the run-queue, the fair_clock variable increases to a fraction of the wall clock.

From poking around the rituals with pthread_create(3), clone is eventually called just like it would in a fork(2).

Now, a process will have a 1:1 model and so will threads. So, does a thread also suffer this same exact fate as well? Obviously, a thread must be punished in some form or else a muti-threaded process can hog most of the CPU time by filling up the RR (round robin) system that CFS uses.

If this is true, then what are the advantages of using threads over forks? Is it just the automatic shared heap space (as opposed to using shm_open(2))?

  • 1
    The doc you link to doesn't describe CFS (the book is from ~ 2000, CFS was introduced in ~2007), that "halving the timeslice" doesn't happen directly with CFS - it doesn't have traditional timeslices.
    – Mat
    Commented Oct 19, 2014 at 7:52
  • Oh, and "just the shared <strike>heap space</strike> address space" is not a detail at all, it is a completely different model from separate processes and requires very different programming techniques.
    – Mat
    Commented Oct 19, 2014 at 7:55
  • @Mat You're right, even the 3rd edition which covers 2.6 was copyrighted in 2006 and from core.c mentions 2007-04-15. Here's to hoping a 4th comes out soon. I'll read some of the code and try to edit the post.
    – SailorCire
    Commented Oct 19, 2014 at 14:36
  • @Mat edited for CFS now and linking to a LJ article.
    – SailorCire
    Commented Oct 21, 2014 at 14:53
  • 1
    Correct, the reason to use a thread rather than a separate process is when you want shared address space. Commented Oct 21, 2014 at 15:59

1 Answer 1


From the link I provided about the Completely Fair Scheduler, we see that in kernel 2.6.24 has what is called group scheduling.

To quote from Chandandeep Singh Pabla:

For example, let's say there is a total of 25 runnable processes in the system. CFS tries to be fair by allocating 4% of the CPU to all of them. However, let's say that out of these 25 processes, 20 belong to user A while 5 belong to user B. User B is at an inherent disadvantage as A is getting more CPU power than B. Group scheduling tries to eliminate this problem. It first tries to be fair to a group and then to individual tasks withing that group. So, CFS with group scheduling enabled, will allocate 50% of the CPU to each user A and B. The allocated 50% share of A will be divided among A's 20 tasks, while the other 50% of the CPU time will be distributed fairly among B's 5 taks.

Now, this applies to the above question, because when a process spawns a new thread, it'll be in that processes scheduling group. This prevents a program that spawns 1000 threads from hogging all of the CPU time, because it'll only get 1/1001th (1000 threads plus the original program) of that particular process group's run time.

So, by slowing down how much time a thread gets compared to the whole system, this properly punishes threaded applications.

  • 1) I can't find the link here; it should be put in the answer anyway; 2) the quote only talks about users getting their own sched groups. But the conclusion written here glosses over that; it implies this will work the same when a system has only one active user running multiple processes.
    – sourcejedi
    Commented Aug 16, 2015 at 10:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .