Jarek Poplawski <[EMAIL PROTECTED]> wrote: > @@ -546,10 +546,10 @@ > When dealing with CPU-CPU interactions, certain types of memory barrier > should > always be paired. A lack of appropriate pairing is almost certainly an > error. > > -A write barrier should always be paired with a data dependency barrier or > read > -barrier, though a general barrier would also be viable. Similarly a read > -barrier or a data dependency barrier should always be paired with at least an > -write barrier, though, again, a general barrier is viable: > +A write barrier should always be paired with a data dependency barrier or a > +read barrier, though a general barrier would also be viable. Similarly the > +read barrier or the data dependency barrier should always be paired with at > +least the write barrier, though, again, the general barrier is viable:
"A" not "the" please. > @@ -1530,7 +1530,8 @@ > If they're used for reference counting on an object to control its lifetime, > they probably don't need memory barriers because either the reference count > will be adjusted inside a locked section, or the caller will already hold > -sufficient references to make the lock, and thus a memory barrier > unnecessary. > +sufficient references to make the lock, and thus the memory barrier > +unnecessary. Hmmm... I'm wondering if that should actually by "a lock". David - 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/
