lkml.org 
[lkml]   [2008]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] Re: using long instead of atomic_t when only set/read is required


    On Mon, 3 Mar 2008, Alan Stern wrote:
    >
    > Consider a routine like the following:
    >
    > static task_struct *the_task;
    >
    > void store_task(void)
    > {
    > the_task = current;
    > }
    >
    > Is it possible to say whether readers examining "the_task" are
    > guaranteed to see a coherent value?

    Yes, we do depend on this. All the RCU stuff (and in general *anything*
    that depends on memory ordering as opposed to full locking, and we have
    quite a lot of it) is very fundamentally dependent on the fact that things
    like pointers get read and written atomically.

    HOWEVER, it is worth pointing out that it's generally true in a
    "different" sense than the actual atomic accesses. For example, if you
    test a single bit of a word, it's still quite possible that gcc will have
    turned that "atomic" read into a single byte read, so it's not necessarily
    the case that we'll actually even read the whole word.

    (Writes are different: if you do things like bitwise updates they simply
    *will*not* be atomic, but that's simply not what we depend on anyway).

    So in that sense, the atomicity guarantees are a lot weaker than the ones
    we do for IO accesses, but that's all fine. Memory isn't IO, and doesn't
    have side effects.

    Linus


    \
     
     \ /
      Last update: 2008-03-03 18:41    [W:0.055 / U:0.484 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site