From owner-freebsd-threads@FreeBSD.ORG Fri Aug 4 15:35:58 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 9FD3016A54F for ; Fri, 4 Aug 2006 15:35:58 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF7BD43D45 for ; Fri, 4 Aug 2006 15:35:57 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k74FZnG4003112; Fri, 4 Aug 2006 11:35:56 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-threads@freebsd.org Date: Fri, 4 Aug 2006 11:34:43 -0400 User-Agent: KMail/1.9.1 References: <20060804140657.GK4498@obiwan.tataz.chchile.org> In-Reply-To: <20060804140657.GK4498@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608041134.43979.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 04 Aug 2006 11:35:57 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Subject: 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: Fri, 04 Aug 2006 15:35:58 -0000 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