From owner-freebsd-threads@FreeBSD.ORG  Fri Jan  7 18:46:39 2005
Return-Path: <owner-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 296B516A4CE
	for <freebsd-threads@freebsd.org>;
	Fri,  7 Jan 2005 18:46:39 +0000 (GMT)
Received: from bute.st-andrews.ac.uk (bute.st-and.ac.uk [138.251.12.1])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0DB1F43D39
	for <freebsd-threads@freebsd.org>;
	Fri,  7 Jan 2005 18:46:38 +0000 (GMT)
	(envelope-from s_sourceforge@nedprod.com)
Received: from kate (res04-ned6.res.st-and.ac.uk [138.251.234.67])
	by bute.st-andrews.ac.uk (8.9.1a/8.9.1) with SMTP id SAA15653
	for <freebsd-threads@freebsd.org>; Fri, 7 Jan 2005 18:44:08 GMT
From: "Niall Douglas" <s_sourceforge@nedprod.com>
To: freebsd-threads@freebsd.org
Date: Fri, 07 Jan 2005 18:46:05 -0000
MIME-Version: 1.0
Message-ID: <41DED8ED.32740.96446B0@localhost>
Priority: normal
In-reply-to: <41DD68DB.6040405@he.iki.fi>
References: <41DD04FE.7070409@freebsd.org>
X-mailer: Pegasus Mail for Windows (4.21c)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Content-Transfer-Encoding: 7BIT
Subject: Re: higher speed mutexes
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jan 2005 18:46:39 -0000

On 6 Jan 2005 at 18:35, Petri Helenius wrote:

> > because we use simple mutex to protect rwlock, if simple mutex is
> > improved, rwlock should be improved by this side effect.
> >
> But rwlock will be significantly more expensive than a simple mutex
> when uncontested, right?

I have a highly optimised rwlock mutex implementation at 
http://svn.berlios.de/viewcvs/tnfox/trunk/src/FXThread.cxx?rev=52&view
=markup. If uncontested, it requires no more than a variable 
increment and a TLS variable increment (with corresponding complexity 
for unlocking) for read locking and four variable increments, three 
variable stores, one TLS variable read for write locking. It's also 
fully recursive.

Cheers,
Niall