lkml.org 
[lkml]   [2007]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/24] make atomic_read() behave consistently across all architectures


    On Wed, 15 Aug 2007, Stefan Richter wrote:

    > Satyam Sharma wrote:
    > > [ BTW, why do we want the compiler to not optimize atomic_read()'s in
    > > the first place? Atomic ops guarantee atomicity, which has nothing
    > > to do with "volatility" -- users that expect "volatility" from
    > > atomic ops are the ones who must be fixed instead, IMHO. ]
    >
    > LDD3 says on page 125: "The following operations are defined for the
    > type [atomic_t] and are guaranteed to be atomic with respect to all
    > processors of an SMP computer."
    >
    > Doesn't "atomic WRT all processors" require volatility?

    No, it definitely doesn't. Why should it?

    "Atomic w.r.t. all processors" is just your normal, simple "atomicity"
    for SMP systems (ensure that that object is modified / set / replaced
    in main memory atomically) and has nothing to do with "volatile"
    behaviour.

    "Volatile behaviour" itself isn't consistently defined (at least
    definitely not consistently implemented in various gcc versions across
    platforms), 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
    care of these". The last "as far as compiler can take care" disclaimer
    comes about due to CPUs doing their own re-ordering nowadays.

    For example (say on i386):

    (A)
    $ cat tp1.c
    int a;

    void func(void)
    {
    a = 10;
    a = 20;
    }
    $ gcc -Os -S tp1.c
    $ cat tp1.s
    ...
    movl $20, a
    ...

    (B)
    $ cat tp2.c
    volatile int a;

    void func(void)
    {
    a = 10;
    a = 20;
    }
    $ gcc -Os -S tp2.c
    $ cat tp2.s
    ...
    movl $10, a
    movl $20, a
    ...

    (C)
    $ cat tp3.c
    int a;

    void func(void)
    {
    *(volatile int *)&a = 10;
    *(volatile int *)&a = 20;
    }
    $ gcc -Os -S tp3.c
    $ cat tp3.s
    ...
    movl $10, a
    movl $20, a
    ...

    In (A) the compiler optimized "a = 10;" away, but the actual store
    of the final value "20" to "a" was still "atomic". (B) and (C) also
    exhibit "volatile" behaviour apart from the "atomicity".

    But as others replied, it seems some callers out there depend upon
    atomic ops exhibiting "volatile" behaviour as well, so that answers
    my initial question, actually. I haven't looked at the code Paul
    pointed me at, but I wonder if that "forget(x)" macro would help
    those cases. I'd wish to avoid the "volatile" primitive, personally.


    Satyam
    -
    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-15 14:21    [W:0.026 / U:61.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site