From owner-freebsd-threads@FreeBSD.ORG Wed Nov 17 19:18:10 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 AA0A916A4CE for ; Wed, 17 Nov 2004 19:18:10 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57C4043D1D for ; Wed, 17 Nov 2004 19:18:10 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) iAHJI2IO000872; Wed, 17 Nov 2004 14:18:05 -0500 (EST) Date: Wed, 17 Nov 2004 14:18:02 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Petri Helenius In-Reply-To: <419BA142.9000801@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-threads@freebsd.org Subject: Re: mutex performance X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 19:18:10 -0000 On Wed, 17 Nov 2004, Petri Helenius wrote: > > Do you feel that mutex performance could be improved from the current > 2-3 million lock/unlock operations per second on uncontested mutexes on > ~2.4Ghz prescott? Which seems to be about 1000 cycles per lock/unlock. I'm not sure what you're trying to say above. > I have a fairly basic producer/consumer application to optimize and I'm > trying to decide on the performance-optimal synchronization method. Mutex performance is not optimal since I designed the low-level locking so that it would work on 80386 which doesn't have cmpxchg. The mutexes are also pointers instead of actual structures, so there's an extra indirection and checks for NULL. libthr mutexes should be faster in the uncontested case since they do use the atomic compare/set primitives. I want to change libpthread locks to drop the 80386 support and just use the atomic primitives for default mutex types. In 6.0, we'll also change all the mutexes, CVs, and semaphores so they aren't pointers -- that will save an indirection and also allow them to be process shared. -- DE