Date: Fri, 4 Aug 2006 11:34:43 -0400 From: John Baldwin <john@baldwin.cx> To: freebsd-threads@freebsd.org Subject: Re: system scope vs. process scope Message-ID: <200608041134.43979.john@baldwin.cx> In-Reply-To: <20060804140657.GK4498@obiwan.tataz.chchile.org> References: <20060804140657.GK4498@obiwan.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608041134.43979.john>