On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote:You need to lock when reading if you insist on consistent data. Even a simple read may be non-atomic (this should be the case for 64bit operations on all our platforms).
Or keep a generation count to detect pre-emption (the devstat code does this, amongst other things), and try again if you lost the race.
Are you sure that code is right? I'm not at all convinced that the compiler is forbidden from simply optimizing away most of your generation count code. (Just because gcc doesn't do so today doesn't mean that icc or gcc 4 won't.)
I'd be a lot more convinced by code that allocated a non-shared buffer, locked the mutex, copied the data into the buffer, unlocked, pushed the data out from the buffer, then released the buffer.
Many attempts to avoid locking are foiled by compiler optimizations.
Tim Kientzle
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
