lkml.org 
[lkml]   [2007]   [Aug]   [16]   [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 Thu, Aug 16, 2007 at 04:56:21PM +1000, Paul Mackerras wrote:
    >
    > Note that I said these are the cases _where one might want to allow
    > caching_, so of course adding volatile doesn't help _these_ cases.
    > There are of course other cases where one definitely doesn't want to
    > allow the compiler to cache the value, such as when polling an atomic
    > variable waiting for another CPU to change it, and from my inspection
    > so far these cases seem to be the majority.

    We've been through that already. If it's a busy-wait it
    should use cpu_relax. If it's scheduling away that already
    forces the compiler to reread anyway.

    Do you have an actual example where volatile is needed?

    > - It matches the normal expectation based on the name "atomic_read"
    > - It matches the behaviour of the other atomic_* primitives

    Can't argue since you left out what those expectations
    or properties are.

    > - It avoids bugs in the cases where "volatile" behaviour is required

    Do you (or anyone else for that matter) have an example of this?

    Cheers,
    --
    Visit Openswan at http://www.openswan.org/
    Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
    Home Page: http://gondor.apana.org.au/~herbert/
    PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
    -
    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-16 09:13    [W:6.651 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site