From owner-freebsd-threads@FreeBSD.ORG Mon Aug 7 21:39:31 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0911416A4DA for ; Mon, 7 Aug 2006 21:39:31 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3894C43D46 for ; Mon, 7 Aug 2006 21:39:20 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id D930724BD0; Mon, 7 Aug 2006 23:39:19 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 1F2949B458; Mon, 7 Aug 2006 21:39:46 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 03121405F; Mon, 7 Aug 2006 23:39:45 +0200 (CEST) Date: Mon, 7 Aug 2006 23:39:45 +0200 From: Jeremie Le Hen To: John Baldwin Message-ID: <20060807213945.GQ4498@obiwan.tataz.chchile.org> References: <20060804140657.GK4498@obiwan.tataz.chchile.org> <200608041134.43979.john@baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608041134.43979.john@baldwin.cx> User-Agent: Mutt/1.5.11 Cc: freebsd-threads@freebsd.org Subject: Re: [fbsd] Re: system scope vs. process scope X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2006 21:39:31 -0000 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 >