Messages in this thread | | | Date | Fri, 17 Aug 2007 16:25:14 +0530 (IST) | From | Satyam Sharma <> | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| |
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 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/
| |