Hi David, On Tue, 24 Jul 2007, David Howells wrote:
> Satyam Sharma <[EMAIL PROTECTED]> wrote: > > > OTOH, as per Linus' review it seems we can drop the "memory" clobber > > and specify the output operand for the extended asm as "+m". But I > > must admit I didn't quite understand that at all. > > As I understand it, the "+m" indicates to the compiler a restriction on the > ordering of things that access that particular memory location, whereas a > "memory" indicates a restriction on the orderings of all accesses to memory - > precisely what you need to produce a lock. Ok, thanks -- I didn't know gcc's behaviour w.r.t. "+m" at all, but in my defense I'd add all this was quite poorly/wrongly documented in the docs. > There are a number of things that use test_and_set_bit() and co to implement a > lock or other synchronisation. This means that they must exhibit LOCK-class > barrier effects or better. LOCK-class barrier effects mean, more or less, > that all memory accesses issued before the lock must happen before all memory > accesses issued after the lock. But it most happen at both CPU-level and > compiler-level. The "memory" constraint instructs the compiler in this > regard. Yes, thanks for laying this out so clearly, again. So combined with what you explained above, I think I now fully understand why most of this series was incorrect ... > Remember also that this is gcc black magic and so some of it has had to be > worked out empirically - possibly after sacrificing a goat under a full moon. :-) Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
