Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH (take 2)] Documentation/memory-barriers.txt: various fixes | Date | Tue, 22 May 2007 13:16:03 +0100 |
| |
Jarek Poplawski <jarkao2@o2.pl> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |