Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Paul E. McKenney <hidden>
Date: 2007-08-16 00:54:44
Also in:
linux-arch, lkml
From: Paul E. McKenney <hidden>
Date: 2007-08-16 00:54:44
Also in:
linux-arch, lkml
On Wed, Aug 15, 2007 at 05:42:07PM -0700, Christoph Lameter wrote:
On Wed, 15 Aug 2007, Paul E. McKenney wrote:quoted
Seems to me that we face greater chance of confusion without the volatile than with, particularly as compiler optimizations become more aggressive. Yes, we could simply disable optimization, but optimization can be quite helpful.A volatile default would disable optimizations for atomic_read. atomic_read without volatile would allow for full optimization by the compiler. Seems that this is what one wants in many cases.
The volatile cast should not disable all that many optimizations, for example, it is much less hurtful than barrier(). Furthermore, the main optimizations disabled (pulling atomic_read() and atomic_set() out of loops) really do need to be disabled. Thanx, Paul