From owner-svn-src-all@FreeBSD.ORG Thu Apr 21 00:56:55 2011 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF22106564A; Thu, 21 Apr 2011 00:56:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id F011A8FC13; Thu, 21 Apr 2011 00:56:54 +0000 (UTC) Received: from c122-106-155-58.carlnfd1.nsw.optusnet.com.au (c122-106-155-58.carlnfd1.nsw.optusnet.com.au [122.106.155.58]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p3L0uoTd030637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 10:56:52 +1000 Date: Thu, 21 Apr 2011 10:56:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <558114287.379554.1303337182943.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20110421104734.S1144@besplex.bde.org> References: <558114287.379554.1303337182943.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, Rick Macklem , svn-src-all@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek Subject: Re: svn commit: r220877 - head/sys/fs/nfsclient X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:56:55 -0000 On Wed, 20 Apr 2011, Rick Macklem wrote: > Well, its value will be consistent, but not necessarily the "up to date" > value set by another thread, if I understood alc@'s recent post. > If you haven't yet read it, take a look at his post today on freebsd-hackers@ > under the Subject > Re: SMP question w.r.t. reading kernel variables I didn't look, but... > If I understood his explanation, a thread must lock a mutex that the thread > that modified the value has locked/unlocked before it is guaranteed to see > that value for the variable instead of some stale memory cached value. > (It can be any mutex, but it is probably much easier to use the same one > that the modifying thread used during modification instead of finding some > other mutex the same thread locked/unlocked after the modification.) I don't see how it can be "any" mutex. "Any" mutex will probably cause some sort of bus lock which will sync the readers and writers at the time of the mutex operation, but not afterwards. I think all that happens is that SMP code executes mutex operations _very_ often. This gives very short race windows which I think hide lots of bugs. Bruce