lkml.org 
[lkml]   [2001]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion
    Linus Torvalds writes:

    > So how about just going all the way and calling it what it is:
    > "data_dependent_read_barrier()", with a notice in the PPC docs about how
    > the PPC cannot speculate reads anyway, so it's a no-op.

    To set the record straight, the PPC architecture spec says that
    implementations *can* speculate reads, but they have to make it look
    as if dependent loads have a read barrier between them.

    And it isn't speculated reads that are the problem in the alpha case,
    it's the fact that the cache can reorder invalidations that are
    received from the bus. That's why you can read the new value of p but
    the old value of *p on one processor after another processor has just
    done something like a = 1; wmb(); p = &a.

    My impression from what Paul McKenney was saying was that on most
    modern architectures other than alpha, dependent loads act as if they
    have a read barrier between them. What we need to know is which
    architectures specify that behaviour in their architecture spec, as
    against those which do that today but which might not do it tomorrow.

    I just looked at the SPARC V9 specification; it has a formal
    definition of the memory model which precludes reordering dependent
    loads (once again this is an "as if" rule). So on ppc and sparc64 we
    have an assurance that we won't need an rmb() between dependent loads
    in the future.

    As for intel x86, is there a architecture spec that talks about things
    like memory ordering? My impression is that the x86 architecture is
    pretty much defined by its implementations but I could well be wrong.

    > too. It's not as if we should ever have that many of them, and when we
    > _do_ have them, they might as well stand out to make it clear that we're
    > doing subtle things.. Although that "data-dependent read barrier" is a lot
    > more subtle than most.

    Indeed... getting the new p but the old *p is quite
    counter-intuitive IMHO.

    Paul.
    -
    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: 2005-03-22 13:08    [W:0.024 / U:30.272 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site