On Wed, 8 Oct 2003, Bernd Walter wrote: BW>On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote: BW>> On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: BW>> +> You need to lock when reading if you insist on consistent data. Even a BW>> +> simple read may be non-atomic (this should be the case for 64bit BW>> +> operations on all our platforms). So you need to do BW>> +> BW>> +> mtx_lock(&foo_mtx); BW>> +> bar = foo; BW>> +> mtx_unlock(&foo_mtx); BW>> +> BW>> +> if foo is a datatype that is not guaranteed to be red atomically. For BW>> +> 8-bit data you should be safe without the lock on any architecture. I'm BW>> +> not sure for 16 and 32 bit, but for 64-bit you need the look for all BW>> +> our architectures, I think. BW>> BW>> But I'm not talking about non-atomic reads. What I'm want to show is that BW>> even atomic read (without lock) is dangerous in some cases. BW>> BW>> +> If you don't care about occasionally reading false data (for statistics or BW>> +> such stuff) you can go without the lock. BW>> BW>> I'm afraid that many developers thinks that atomic reads are always safe BW>> without locks (there are many such reads in sources). I hope I'm wrong. BW> BW>It depends on the architecture and usage. BW>bar = foo might be non-interruptable, but that doesn't say anything BW>about cache consistency. BW>If foo was written by another thread then you can have trouble with BW>register caching unless the variable is volatile. BW>If the other thread was/is running on another CPU then you might read BW>an outdated value from cache. BW>mtx_lock/mtx_unlock takes care about caching. BW> BW>However - if you read a value (e.g.) for statistic output - then it BW>won't hurt to get a cached value which is a few subseconds behind the BW>real value. BW>The only point to take care in this case is that the read is atomic and BW>that all bytes in the read value are consistent. BW> BW>The above mtx_lock/read/mt_unlock case doesn't make sense, because it BW>only garanties an up to date value, but you cache it in a local BW>variable which again brings it out of date when used outside the lock.
You might (for what ever reason) not care that the value gets out of date later on, but care that it is correct and consistent in itself. In this case, if foo is large (64-bit or a structure) the mtx_lock/read/mtx_unlock makes perfect sense because it guarantees that the value is not changed while you're copying it (non-atomically). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
