[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
    Nick Piggin writes:

    > Why are people making these undocumented and just plain false
    > assumptions about atomic_t?

    Well, it has only been false since December 2006. Prior to that
    atomics *were* volatile on all platforms.

    > If they're using lockless code (ie.
    > which they must be if using atomics), then they actually need to be
    > thinking much harder about memory ordering issues.

    Indeed. I believe that most uses of atomic_read other than in polling
    loops or debug printk statements are actually racy. In some cases the
    race doesn't seem to matter, but I'm sure there are cases where it

    > If that is too
    > much for them, then they can just use locks.

    Why use locks when you can just sprinkle magic fix-the-races dust (aka
    atomic_t) over your code? :) :)

    > > Precisely. And volatility is a key property of "atomic". Let's please
    > > not throw it away.
    > It isn't, though (at least not since i386 and x86-64 don't have it).

    Conceptually it is, because atomic_t is specifically for variables
    which are liable to be modified by other CPUs, and volatile _means_
    "liable to be changed by mechanisms outside the knowledge of the

    > _Adding_ it is trivial, and can be done any time. Throwing it away
    > (ie. making the API weaker) is _hard_. So let's not add it without

    Well, in one sense it's not that hard - Linus did it just 8 months ago
    in commit f9e9dcb3. :)

    > really good reasons. It most definitely results in worse code
    > generation in practice.

    0.0008% increase in kernel text size on powerpc according to my
    measurement. :)

    > I don't know why people would assume volatile of atomics. AFAIK, most

    By making something an atomic_t you're saying "other CPUs are going to
    be modifying this, so treat it specially". It's reasonable to assume
    that special treatment extends to reading and setting it.

    > of the documentation is pretty clear that all the atomic stuff can be
    > reordered etc. except for those that modify and return a value.

    Volatility isn't primarily about reordering (though as Linus says it
    does restrict reordering to some extent).

    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 06:05    [W:0.028 / U:30.904 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site