[lkml]   [2007]   [Aug]   [15]   [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

    On Wed, 15 Aug 2007, Segher Boessenkool wrote:

    > > "Volatile behaviour" itself isn't consistently defined (at least
    > > definitely not consistently implemented in various gcc versions across
    > > platforms),
    > It should be consistent across platforms; if not, file a bug please.
    > > but it is /expected/ to mean something like: "ensure that
    > > every such access actually goes all the way to memory, and is not
    > > re-ordered w.r.t. to other accesses, as far as the compiler can take

    (or, alternatively, "other accesses to the same volatile object" ...)

    > > care of these". The last "as far as compiler can take care" disclaimer
    > > comes about due to CPUs doing their own re-ordering nowadays.
    > You can *expect* whatever you want, but this isn't in line with
    > reality at all.
    > volatile _does not_ prevent reordering wrt other accesses.
    > [...]
    > What volatile does are a) never optimise away a read (or write)
    > to the object, since the data can change in ways the compiler
    > cannot see; and b) never move stores to the object across a
    > sequence point. This does not mean other accesses cannot be
    > reordered wrt the volatile access.
    > If the abstract machine would do an access to a volatile-
    > qualified object, the generated machine code will do that
    > access too. But, for example, it can still be optimised
    > away by the compiler, if it can prove it is allowed to.

    As (now) indicated above, I had meant multiple volatile accesses to
    the same object, obviously.


    #define atomic_read(a) (*(volatile int *)&(a))
    #define atomic_set(a,i) (*(volatile int *)&(a) = (i))

    int a;

    void func(void)
    int b;

    b = atomic_read(a);
    atomic_set(a, 20);
    b = atomic_read(a);


    pushl %ebp
    movl a, %eax
    movl %esp, %ebp
    movl $20, a
    movl a, %eax
    popl %ebp

    so the first atomic_read() wasn't optimized away.

    > volatile _does not_ make accesses go all the way to memory.
    > [...]
    > If you want stuff to go all the way to memory, you need some
    > architecture-specific flush sequence; to make a store globally
    > visible before another store, you need mb(); before some following
    > read, you need mb(); to prevent reordering you need a barrier.

    Sure, which explains the "as far as the compiler can take care" bit.
    Poor phrase / choice of words, probably.
    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-15 21:31    [W:0.024 / U:4.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site