Would a process with more threads on Linux have more cpu time than a process with one thread?
In Linux processes and threads are described by a task struct, and scheduling is based on tasks. I found also this:
When a new process is created,
do_fork()
sets the counter field of both current (the parent) and p (the child) processes in the following way:current->counter >>= 1; p->counter = current->counter;
In other words, the number of ticks left to the parent is split in two halves, one for the parent and one for the child. This is done to prevent users from getting an unlimited amount of CPU time by using the following method: the parent process creates a child process that runs the same code and then kills itself; by properly adjusting the creation rate, the child process would always get a fresh quantum before the quantum of its parent expires. This programming trick does not work since the kernel does not reward forks. Similarly, a user cannot hog an unfair share of the processor by starting lots of background processes in a shell or by opening a lot of windows on a graphical desktop. More generally speaking, a process cannot hog resources (unless it has privileges to give itself a real-time policy) by forking multiple descendants.
Actually I didn't find that in the kernel sources, but maybe it's my fault, maybe I saw wrong kernel version.
But what happens later, would every thread participate in scheduling like a separate process? Would a process with ten threads get ten times more ticks than a process with one thread? What about IO in this sense?
See Question&Answers more detail:os