system scope vs. process scope

[John Baldwin]

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