lkml.org 
[lkml]   [2007]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH (take 2)] Documentation/memory-barriers.txt: various fixes
    Date
    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/

    \
     
     \ /
      Last update: 2007-05-22 14:19    [W:0.020 / U:1.624 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site