From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 19 18:46:20 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C2001065693 for ; Tue, 19 Jan 2010 18:46:20 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id D604A8FC29 for ; Tue, 19 Jan 2010 18:46:19 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id o0JIkIGM027120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jan 2010 12:46:19 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.4/8.14.3) with ESMTP id o0JIkIDh019435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jan 2010 12:46:18 -0600 (CST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.4/8.14.3/Submit) id o0JIkI7D019433; Tue, 19 Jan 2010 12:46:18 -0600 (CST) (envelope-from dan) Date: Tue, 19 Jan 2010 12:46:17 -0600 From: Dan Nelson To: Bernard van Gastel Message-ID: <20100119184617.GB50360@dan.emsphone.com> References: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71A129DC-68A0-46C3-956D-C8AFF1BA29E1@bitpowder.com> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Tue, 19 Jan 2010 12:46:19 -0600 (CST) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-hackers@freebsd.org Subject: Re: pthread_{mutex,cond} & fifo/starvation/scheduling policy X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 18:46:20 -0000 In the last episode (Jan 19), Bernard van Gastel said: > I'm curious to the exact scheduling policy of POSIX threads in relation to > mutexes and conditions. If there are two threads (a & b), both with the > following code: > > while (1) { > pthread_mutex_lock(mutex); > ... > pthread_mutex_unlock(mutex); > } > > What is the scheduling policy of the different thread libraries? Are both > threads getting an equal amount of time? Are there no starvation issues > (are they executed in alternating turns)? (a test program of mine > indicates that libpthread and libthr both have starvation issues, in > contrary to Mac OS X 10.6) There's no guarantee of fairness when dealing with mutexes afaik. My guess is that if thread "a" unlocks the mutex and still has time left in its quantum, it'll be able to grab it again without even going to the kernel. >From the POSIX docs on mutexes: http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html#tag_16_439_08 "Mutex objects are intended to serve as a low-level primitive from which other thread synchronization functions can be built. As such, the implementation of mutexes should be as efficient as possible, and this has ramifications on the features available at the interface. The mutex functions and the particular default settings of the mutex attributes have been motivated by the desire to not preclude fast, inlined implementations of mutex locking and unlocking." The idea being that mutexes should be held for as little time as possible. Is there a way to write your code so that most of the CPU-consuming activity is done outside of the mutex? Perhaps use a job queue of some sort, and only lock the mutex when pushing/popping elements. Then worker processes can run without holding the mutex, and will be fairly scheduled by the kernel. -- Dan Nelson dnelson@allantgroup.com