On Fri, 17 Aug 2007, Nick Piggin wrote: > Satyam Sharma wrote: > > [...] > > The point is about *author expecations*. If people do expect atomic_read() > > (or a variant thereof) to have volatile semantics, why not give them such > > a variant? > > Because they should be thinking about them in terms of barriers, over > which the compiler / CPU is not to reorder accesses or cache memory > operations, rather than "special" "volatile" accesses. This is obviously just a taste thing. Whether to have that forget(x) barrier as something author should explicitly sprinkle appropriately in appropriate places in the code by himself or use a primitive that includes it itself. I'm not saying "taste matters aren't important" (they are), but I'm really skeptical if most folks would find the former tasteful. > > And by the way, the point is *also* about the fact that cpu_relax(), as > > of today, implies a full memory clobber, which is not what a lot of such > > loops want. (due to stuff mentioned elsewhere, summarized in that summary) > > That's not the point, That's definitely the point, why not. This is why "barrier()", being heavy-handed, is not the best option. > because as I also mentioned, the logical extention > to Linux's barrier API to handle this is the order(x) macro. Again, not > special volatile accessors. Sure, that forget(x) macro _is_ proposed to be made part of the generic API. Doesn't explain why not to define/use primitives that has volatility semantics in itself, though (taste matters apart). - 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 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: Paul Mackerras <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Linus Torvalds <[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: Satyam Sharma <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Nick Piggin <[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: Nick Piggin <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Prev by Date: Re: nf_conntrack_ipv4 must be loaded explicitly
- Next by Date: recursive use of bust_spinlocks()
- 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):
 |