[lkml]   [2007]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures
    Stefan Richter wrote:
    > Nick Piggin wrote:
    >>I don't know why people would assume volatile of atomics. AFAIK, most
    >>of the documentation is pretty clear that all the atomic stuff can be
    >>reordered etc. except for those that modify and return a value.
    > Which documentation is there?


    > For driver authors, there is LDD3. It doesn't specifically cover
    > effects of optimization on accesses to atomic_t.
    > For architecture port authors, there is Documentation/atomic_ops.txt.
    > Driver authors also can learn something from that document, as it
    > indirectly documents the atomic_t and bitops APIs.

    "Semantics and Behavior of Atomic and Bitmask Operations" is
    pretty direct :)

    Sure, it says that it's for arch maintainers, but there is no
    reason why users can't make use of it.

    > Prompted by this thread, I reread this document, and indeed, the
    > sentence "Unlike the above routines, it is required that explicit memory
    > barriers are performed before and after [atomic_{inc,dec}_return]"
    > indicates that atomic_read (one of the "above routines") is very
    > different from all other atomic_t accessors that return values.
    > This is strange. Why is it that atomic_read stands out that way? IMO

    It is not just atomic_read of course. It is atomic_add,sub,inc,dec,set.

    > this API imbalance is quite unexpected by many people. Wouldn't it be
    > beneficial to change the atomic_read API to behave the same like all
    > other atomic_t accessors that return values?

    It is very consistent and well defined. Operations which both modify
    the data _and_ return something are defined to have full barriers
    before and after.

    What do you want to add to the other atomic accessors? Full memory
    barriers? Only compiler barriers? It's quite likely that if you think
    some barriers will fix bugs, then there are other bugs lurking there

    Just use spinlocks if you're not absolutely clear about potential
    races and memory ordering issues -- they're pretty cheap and simple.

    > OK, it is also different from the other accessors that return data in so
    > far as it doesn't modify the data. But as driver "author", i.e. user of
    > the API, I can't see much use of an atomic_read that can be reordered
    > and, more importantly, can be optimized away by the compiler.

    It will return to you an atomic snapshot of the data (loaded from
    memory at some point since the last compiler barrier). All you have
    to be aware of compiler barriers and the Linux SMP memory ordering
    model, which should be a given if you are writing lockless code.

    > Sure, now
    > that I learned of these properties I can start to audit code and insert
    > barriers where I believe they are needed, but this simply means that
    > almost all occurrences of atomic_read will get barriers (unless there
    > already are implicit but more or less obvious barriers like msleep).

    You might find that these places that appear to need barriers are
    buggy for other reasons anyway. Can you point to some in-tree code
    we can have a look at?

    SUSE Labs, Novell Inc.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-17 10:09    [W:0.030 / U:35.516 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site