svn commit: r220877 - head/sys/fs/nfsclient

Bruce Evans brde at optusnet.com.au
Thu Apr 21 00:56:55 UTC 2011


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


More information about the svn-src-head mailing list