From owner-cvs-src@FreeBSD.ORG Mon Oct 29 21:43:35 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14B3916A421; Mon, 29 Oct 2007 21:43:35 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 94CE713C447; Mon, 29 Oct 2007 21:43:34 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l9TLh2Zr024857; Mon, 29 Oct 2007 17:43:02 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.netplex.net [204.213.176.10]); Mon, 29 Oct 2007 17:43:03 -0400 (EDT) Date: Mon, 29 Oct 2007 17:43:02 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kris Kennaway In-Reply-To: <472650BF.5060706@FreeBSD.org> Message-ID: References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <472650BF.5060706@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2007 21:43:35 -0000 On Mon, 29 Oct 2007, Kris Kennaway wrote: > Daniel Eischen wrote: >> >> The libkse implementation already spins for a bit. The default >> number of spins is 500. > > OK, cool. > >> I'm not sure that another mutex type is warranted, the default >> mutex implementation should be adaptive I think. > > The point being that certain existing applications already know about this > mutex name and will use it automatically when it exists. > > I am a bit wary of making this the default type though. The algorithm is a > pessimization when the conditions described above are not true. I agree, and it applies a little to the KSE approach also. Spinning is mostly a hack for not being able to tell in userland if a thread is swapped in/out or is on another CPU. If you solve that problem, then you can make the default mutex adaptive. In KSE, it was a little easier, because we could set a flag in the thread's mailbox to tell the scheduler that it was in a critical region, so no other thread from that process would be run on that KSE until it was out of the critical region. Low-level locks in KSE were always taken while in these critical regions, so if it tried to acquire a lock that was already taken, it knew it must be running on a different KSE (and in theory a different CPU, although binding KSEs to CPUs was never implemented). Even with this approach, libkse still didn't know if the thread was active or swapped out on another CPU. It would have been cool to have the scheduler indicate this with a flag in the thread's mailbox. -- DE