[lkml]   [2007]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] ipvs: force read of atomic_t in while loop
    On Wed, 08 Aug 2007 17:08:44 -0400
    Chris Snook <> wrote:

    > Heiko Carstens wrote:
    > > On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
    > >> From: Heiko Carstens <>
    > >> Date: Wed, 8 Aug 2007 11:33:00 +0200
    > >>
    > >>> Just saw this while grepping for atomic_reads in a while loops.
    > >>> Maybe we should re-add the volatile to atomic_t. Not sure.
    > >> I think whatever the choice, it should be done consistently
    > >> on every architecture.
    > >>
    > >> It's just asking for trouble if your arch does it differently from
    > >> every other.
    > >
    > > Well..currently it's i386/x86_64 and s390 which have no volatile
    > > in atomic_t. And yes, of course I agree it should be consistent
    > > across all architectures. But it isn't.
    > Based on recent discussion, it's pretty clear that there's a lot of
    > confusion about this. A lot of people (myself included, until I thought
    > about it long and hard) will reasonably assume that calling
    > atomic_read() will actually read the value from memory. Leaving out the
    > volatile declaration seems like a pessimization to me. If you force
    > people to use barrier() everywhere they're working with atomic_t, it
    > will force re-reads of all the non-atomic data in use as well, which
    > will cause more memory fetches of things that generally don't need
    > barrier(). That and it's a bug waiting to happen.
    > Andi -- your thoughts on the matter?

    I'm not Andi, but this not-Andi thinks that permitting the compiler to cache
    the results of atomic_read() is dumb.

    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-08 23:39    [W:0.023 / U:1.688 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site