No it does not have any volatile semantics. atomic_dec() can be reordered at will by the compiler within the current basic unit if you do not add abarrier."volatile" has nothing to do with reordering.If you're talking of "volatile" the type-qualifier keyword, then http://lkml.org/lkml/2007/8/16/231 (and sub-thread below it) shows otherwise.
I'm not sure what in that mail you mean, but anyway... Yes, of course, the fact that "volatile" creates a side effect prevents certain things from being reordered wrt the atomic_dec(); but the atomic_dec() has a side effect *already* so the volatile doesn't change anything.
atomic_dec() writes to memory, so it _does_ have "volatile semantics", implicitly, as long as the compiler cannot optimise the atomic variable away completely -- any store counts as a side effect.I don't think an atomic_dec() implemented as an inline "asm volatile" or one that uses a "forget" macro would have the same re-ordering guarantees as an atomic_dec() that uses a volatile access cast.
The "asm volatile" implementation does have exactly the same reordering guarantees as the "volatile cast" thing, if that is implemented by GCC in the "obvious" way. Even a "plain" asm() will do the same. Segher - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: "Paul E. McKenney" <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Christoph Lameter <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Paul Mackerras <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Herbert Xu <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Paul Mackerras <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Satyam Sharma <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Satyam Sharma <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Paul Mackerras <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Herbert Xu <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Paul Mackerras <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Herbert Xu <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: "Ilpo Järvinen" <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Chris Snook <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Christoph Lameter <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Segher Boessenkool <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Satyam Sharma <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Prev by Date: Re: [PATCH] [5/12] x86_64: Make patching more robust, fix paravirt issue
- Next by Date: [PATCH 0/3] allow drivers to flush in-flight DMA
- Previous by thread: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Next by thread: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Index(es):
 |