Messages in this thread |  | | | Date | Fri, 17 Aug 2007 19:31:11 +1000 | | From | Nick Piggin <> | | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| |
Satyam Sharma wrote: > > On Fri, 17 Aug 2007, Nick Piggin wrote: > > >>Satyam Sharma wrote: >>[...] >> >>>Granted, the above IS buggy code. But, the stated objective is to avoid >>>heisenbugs. > > ^^^^^^^^^^ > > >>Anyway, why are you making up code snippets that are buggy in other >>ways in order to support this assertion being made that lots of kernel >>code supposedly depends on volatile semantics. Just reference the >>actual code. > > > Because the point is *not* about existing bugs in kernel code. At some > point Chris Snook (who started this thread) did write that "If I knew > of the existing bugs in the kernel, I would be sending patches for them, > not this series" or something to that effect. > > 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. Linux's whole memory ordering and locking model is completely geared around the former.
> 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, 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. - 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/
|  |