On Thu, Aug 16, 2007 at 01:23:06PM +1000, Paul Mackerras wrote: > > In particular, atomic_read seems to lend itself to buggy uses. People > seem to do things like: > > atomic_add(&v, something); > if (atomic_read(&v) > something_else) ...
If you're referring to the code in sk_stream_mem_schedule then it's working as intended. The atomicity guarantees that the atomic_add/atomic_sub won't be seen in parts by other readers. We certainly do not need to see other atomic_add/atomic_sub operations immediately. If you're referring to another code snippet please cite. > I'd go so far as to say that anywhere where you want a non-"volatile" > atomic_read, either your code is buggy, or else an int would work just > as well. An int won't work here because += and -= do not have the atomicity guarantees that atomic_add/atomic_sub do. In particular, this may cause an atomic_read on another CPU to give a bogus reading. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> 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 netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
