lkml.org 
[lkml]   [2007]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: why are some atomic_t's not volatile, while most are?
    Zan Lynx wrote:
    > On Tue, 2007-08-07 at 15:38 -0600, Chris Friesen wrote:
    >> Chris Snook wrote:
    >>
    >>> That's why we define atomic_read like so:
    >>>
    >>> #define atomic_read(v) ((v)->counter)
    >>>
    >>> This avoids the aliasing problem, because the compiler must de-reference
    >>> the pointer every time, which requires a memory fetch.
    >> Can you guarantee that the pointer dereference cannot be optimised away
    >> on any architecture? Without other restrictions, a suficiently
    >> intelligent optimiser could notice that the address of v doesn't change
    >> in the loop and the destination is never written within the loop, so the
    >> read could be hoisted out of the loop.
    >>
    >> Even now, powerpc (as an example) defines atomic_t as:
    >>
    >> typedef struct { volatile int counter; } atomic_t
    >>
    >>
    >> That volatile is there precisely to force the compiler to dereference it
    >> every single time.
    >
    > I just tried this with GCC 4.2 on x86_64 because I was curious.
    >
    > struct counter_t { volatile int counter; } test;
    > struct counter_t *tptr = &test;
    >
    > int main() {
    > int i;
    >
    > tptr->counter = 0;
    > i = 0;
    > while(tptr->counter < 100) {
    > i++;
    > }
    > return 0;
    > }
    >
    > $ gcc -O3 -S t.c
    >
    > a snippet of t.s:
    > main:
    > .LFB2:
    > movq tptr(%rip), %rdx
    > movl $0, (%rdx)
    > .p2align 4,,7
    > .L2:
    > movl (%rdx), %eax
    > cmpl $99, %eax
    > jle .L2
    >
    >
    > Now with the volatile removed:
    > main:
    > .LFB2:
    > movq tptr(%rip), %rax
    > movl $0, (%rax)
    > .L2:
    > jmp .L2
    >
    > If the compiler can see it clearly, it will optimize out the load
    > without the volatile.

    This is not a problem, since indirect references will cause the CPU to fetch the
    data from memory/cache anyway.

    -- Chris
    -
    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-08 03:35    [W:0.028 / U:33.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site