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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
