Date: Mon, 7 Aug 2006 23:39:45 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: John Baldwin <john@baldwin.cx> Cc: freebsd-threads@freebsd.org Subject: Re: [fbsd] Re: system scope vs. process scope Message-ID: <20060807213945.GQ4498@obiwan.tataz.chchile.org> In-Reply-To: <200608041134.43979.john@baldwin.cx> References: <20060804140657.GK4498@obiwan.tataz.chchile.org> <200608041134.43979.john@baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi John, On Fri, Aug 04, 2006 at 11:34:43AM -0400, John Baldwin wrote: > 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. Thank you very much for your explanation. I have some difficulties though to understand why this is a thread attribute, not process-wide. This implies that threads inside one process may be either PTHREAD_SCOPE_SYSTEM or PTHREAD_SCOPE_PROCESS. I don't really get the point in doing this, except if this how libpthread manages to achieve M:N threading. > 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. How d those two attributes modify libpthread behaviour in regards to M:N scheduling ? I am quite puzzled about this. > (To some extent > libpthread needs some help from the kernel to provide this as well.) Scheduler Activations ? Thank you very much. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060807213945.GQ4498>