lkml.org 
[lkml]   [2004]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: What does atomic_read actually do?
    Date
    On Mon, 20 Dec 2004 13:52:23 +0100, Andrea Arcangeli <andrea@suse.de>  
    wrote:
    >
    > set_pte_atomic also requires atomicity in
    > asm-generic/pgtable.h:ptep_establish, but it's not even using volatile
    > and it's a 64bit pointer that we're writing to. We're relaying on the
    > compiler to do the right thing for us. I don't think it's a good idea
    > for the long run, but Benjamin on ppc64 rejected my suggestion to
    > rewrite set_pte_atomic in asm, so I doubt you'll be able to rewrite
    > atomic_read with asm either (because at least atomic_read is an int and
    > not a long pointer, and at least atomic_read is a volatile unlike
    > set_pte).
    >
    > My point is that even before worrying about the theoretical correctness
    > of atomic_read, I would suggest to worry about set_pte_atomic first,
    > which is a lot more likely to break if something. The compiler may truly
    > execute two separate writes if power of 2 bitshifts are involved, as the
    > optimal compilation of the C source.

    Actually, I'm programming out in user space. I was looking at the atomic.h
    stuff to see how much would be usable. But I have to look at reading
    and writing pointers atomically also since that is heavily used in
    lock-free
    programming, e.g. RCU for preemptive user threads which I have a couple of
    implementations for. I remember a discussion a while back about dependent
    load memory ordering (alpha doesn't have it) for RCU but I don't recall any
    discussion of the requirement for gcc to do atomic loads and stores. I
    guess
    it's just assumed.

    It would be nice to have macros tied to the linux ones, ie. check the
    current
    linux versions when porting them. But I can always use asm if I have to.
    I'll
    probably have to modify the conditions of use to say "no warranty is
    implied
    and we really do mean it" and add a compiler flag to select between the
    safe asm
    version and the "Do you feel lucky?" C macro version.

    Joe Seigh

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