[fbsd] Re: system scope vs. process scope
Jeremie Le Hen
jeremie at le-hen.org
Mon Aug 7 21:39:31 UTC 2006
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 >
More information about the freebsd-threads
mailing list