From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 19 21:06:02 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 063F416A401 for ; Mon, 19 Mar 2007 21:06:02 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C1D9413C4E8 for ; Mon, 19 Mar 2007 21:06:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l2JL5xIk005337; Mon, 19 Mar 2007 17:05:59 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Mon, 19 Mar 2007 17:05:59 -0400 (EDT) Date: Mon, 19 Mar 2007 17:05:59 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Joerg Sonnenberger In-Reply-To: <20070319204048.GB24514@britannica.bec.de> Message-ID: References: <20070319175908.35326.qmail@web32911.mail.mud.yahoo.com> <20070319204048.GB24514@britannica.bec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Pthread spin locks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 21:06:02 -0000 On Mon, 19 Mar 2007, Joerg Sonnenberger wrote: > On Mon, Mar 19, 2007 at 02:04:58PM -0400, Daniel Eischen wrote: >> No, especially if the threads hold other locks. >> I have no idea why POSIX added spinlocks. I don't >> see why anyone would want to use them. > > Given that it is part of the realtime extensions, it makes sense. On > those systems you generally also have policies for scheduler control > like CPU affinity, which can make the starvation impossible. PTHREAD_PRIO_PROTECT and PTHREAD_PRIO_INHERIT POSIX doesn't seem to have specified APIs for scheduler affinity and has said that the behavior of threads in scheduling domains > 1 is implementation defined. So it is somewhat surprising to me that spinlocks were added. It also assumes that the implementation of non-spin mutexes is inefficient which is not necessarily the case. It is certainly possible for the implementation to use adaptive mutexes which spin for a bit before sleeping. -- DE