From owner-cvs-all@FreeBSD.ORG  Mon Oct 29 21:52:13 2007
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id EE65C16A420;
	Mon, 29 Oct 2007 21:52:13 +0000 (UTC)
	(envelope-from kris@FreeBSD.org)
Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b])
	by mx1.freebsd.org (Postfix) with ESMTP id E55C613C48D;
	Mon, 29 Oct 2007 21:52:12 +0000 (UTC)
	(envelope-from kris@FreeBSD.org)
Message-ID: <4726560F.5050804@FreeBSD.org>
Date: Mon, 29 Oct 2007 22:52:15 +0100
From: Kris Kennaway <kris@FreeBSD.org>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Daniel Eischen <deischen@freebsd.org>
References: <200710292101.l9TL1mAE049561@repoman.freebsd.org>
	<Pine.GSO.4.64.0710291712100.19572@sea.ntplx.net>
	<472650BF.5060706@FreeBSD.org>
	<Pine.GSO.4.64.0710291732090.19572@sea.ntplx.net>
In-Reply-To: <Pine.GSO.4.64.0710291732090.19572@sea.ntplx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2007 21:52:14 -0000

Daniel Eischen wrote:
> 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.

Yeah.  It looks like Solaris does this.  In principle you could do it 
cheaply with a shared page, I'm not sure what Solaris does.

One further optimization that can be done is for umtx to also spin when 
the mutex holder is running instead of sleeping immediately.  Jeff and I 
hope to look at this.

Kris