From owner-freebsd-threads@FreeBSD.ORG Fri Nov 19 09:19:56 2004 Return-Path: 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 96F2216A4CE for ; Fri, 19 Nov 2004 09:19:56 +0000 (GMT) Received: from psych.st-andrews.ac.uk (psych.st-and.ac.uk [138.251.11.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C497843D58 for ; Fri, 19 Nov 2004 09:19:55 +0000 (GMT) (envelope-from s_sourceforge@nedprod.com) Received: from kate (res04-ned6.res.st-and.ac.uk [138.251.234.67]) by psych.st-andrews.ac.uk (8.9.1a/8.9.1) with SMTP id JAA19965 for ; Fri, 19 Nov 2004 09:19:54 GMT From: "Niall Douglas" To: Petri Helenius Date: Fri, 19 Nov 2004 09:19:36 -0000 MIME-Version: 1.0 Message-ID: <419DBAA8.29867.1D449929@localhost> Priority: normal In-reply-to: <419DA9B9.50105@he.iki.fi> References: <419DA7EC.20473.1CFB6AE9@localhost> X-PM-Encryptor: IDWPGP-PM32, 4 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 cc: freebsd-threads@freebsd.org Subject: Re: mutex performance X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2004 09:19:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2004 at 10:07, Petri Helenius wrote: > >This is on a dual Athon 1700 (1.43Ghz), so that's 77.76 cycles per > >lock/unlock with SMP build and 52.28 cycles on non-SMP build. The > >difference between SMP and non-SMP is that the former uses the lock > >prefix on the x86 instructions. > > > >So yes, I think there is some scope for improvement. > > > Are these mutexes spinlocks or "real" locks which make the thread > actually yield if they have to wait longer? Or should I RTFS? :-) You would have had to read the source actually. I wrote them as I was very unhappy with the performance of the locks supplied by Win2k which are far slower than the same code on WinNT 4.0. They're also far faster than most pthread lock implementations. Here's the schema: 1. Is lock free? If so take possession and exit 2. Is lock already held by this thread? If so, increment refcount and exit 3. If on multiprocessor, examine lock's freeness X times (default 4000). If still not free, ask kernel to suspend me. If on uniprocessor or non-SMP build, ask kernel to switch immediately to next thread. The key to the high performance is the use of "lock inc" - a lot of the time we don't care about what the value is, just that it is or isn't zero. By using inc and dec instead of xadd I gained quite a few percent if I remember plus it's a lot faster without the lock prefix. Of course, I have no idea what performance would be like on Intel chips. It's likely that the many branches would penalise code though I have used the pause x86 instruction where possible. Cheers, Niall -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBQZ26qMEcvDLFGKbPEQIpGQCg124mjqWElk4cP/LpNtRUgEMO7a8An0ye M/Ku1yACotLlZDyvpPdWI1cC =/p1K -----END PGP SIGNATURE-----