lkml.org 
[lkml]   [2007]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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
    does.

    > 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
    compiler".

    > _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).

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