system scope vs. process scope
John Baldwin
john at baldwin.cx
Fri Aug 4 15:35:58 UTC 2006
On Friday 04 August 2006 10:06, Jeremie Le Hen wrote:
> Hi,
>
> occasionally, I saw environnement variables LIBPTHREAD_SYSTEM_SCOPE and
> LIBPTHREAD_PROCESS_SCOPE mentionned hither and thither. I grep(1)'ed
> through the source tree for some documentation, but I wasn't able to
> find any. Read the source Luke...
>
> It seems that the PTHREAD_SCOPE_SYSTEM thread attribute is the default.
> Intuitivelely, I would say that setting the PTHREAD_SCOPE_PROCESS
> attribute creates a new process with its address space being shared with
> the other userland threads (a la Linux) whereas the default behaviour is
> to create a new kernel thread.
>
> Am I right ? What are the pros and cons of either methods ?
That's not what it means. :) It has to do with scheduling. A
PTHREAD_SCOPE_SYSTEM will compete for the CPU with other "system" threads
(aka kernel threads). That is, each userland thread has a direct kernel
thread that is visible to the system (kernel). A PTHREAD_SCOPE_PROCESS
thread competes for the CPU just within the current process. That is, each
group of PTHREAD_SCOPE_PROCESS thread's all share (in theory) a single kernel
thread that competes for CPU with other system threads. An example might
explain the theory more completely.
Suppose you have a system with 2 processes. One process is single-threaded
and is CPU bound. The other process has 2 threads both of which are also CPU
bound. If the threads in the second process are PTHREAD_SCOPE_SYSTEM, then
each thread will get 33% of the CPU. If the threads in the second process
are PTHREAD_SCOPE_PROCESS, then the each process will get 50% of the CPU.
The second process will then use its own algorithm to split it's 50% of the
CPU up between it's two threads. If it divides it evenly, then each of its'
threads will end up with 25% of the CPU whereas the thread for the first
process has 50% of the CPU. The idea for this is that if you have a system
with several single-threaded processes and one process with 1000 threads, you
don't want that process to starve out all the other processes.
In practice things get much hairier, but suffice it to say that libpthread
manages the scheduling of PTHREAD_SCOPE_PROCESS threads in userland, whereas
libthr would have to depend on the kernel managing that. (To some extent
libpthread needs some help from the kernel to provide this as well.)
--
John Baldwin
More information about the freebsd-threads
mailing list