From owner-cvs-all@FreeBSD.ORG Tue Jun 15 01:12:11 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 395F716A4CE; Tue, 15 Jun 2004 01:12:11 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CB7043D31; Tue, 15 Jun 2004 01:12:11 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B65FA5C7EB; Mon, 14 Jun 2004 18:12:10 -0700 (PDT) Date: Mon, 14 Jun 2004 18:12:10 -0700 From: Alfred Perlstein To: Daniel Eischen Message-ID: <20040615011210.GN61448@elvis.mu.org> References: <20040614194836.GJ61448@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: Maxime Henrion cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/conf GENERIC X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2004 01:12:11 -0000 * Daniel Eischen [040614 13:09] wrote: > On Mon, 14 Jun 2004, Alfred Perlstein wrote: > > > DbEnv::set_tas_spins > > > > Specify that test-and-set mutexes should spin tas_spins times without > > blocking. The value defaults to 1 on uniprocessor systems and to 50 > > times the number of processors on multiprocessor systems. > > > > The database environment's test-and-set spin count may also be set > > using the environment's DB_CONFIG file. The syntax of the entry in > > that file is a single line with the string "set_tas_spins", one or > > more whitespace characters, and the number of spins. Because the > > DB_CONFIG file is read when the database environment is opened, it > > will silently overrule configuration done before that time. > > I think you're missing his point. Adaptive mutexes _do_ spin. > The optimization is that they spin for only as long as the > current owner is running (on another CPU). If the owner is > not running or stops running, the thread blocks. > > The kernel knows about its threads, which thread owns a > mutex, and whether that thread is running. And since > the desire is for mutexes to be held for short periods, it > is better for the requesting thread to spin as long as the > owning thread is running. And conversely, it doesn't make > sense to spin if the owning thread isn't running. I understand what you're saying. It's just that it seems that we now have some subsystem locks where spinning as long as the holder is running might be too long. I said "might" I didn't say "will". It might be interesting to put an upper bound on the amount of spins. Anyhow. :) -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684