Messages in this thread | | | Date | Thu, 9 Aug 2007 08:37:27 -0400 (EDT) | From | "Robert P. J. Day" <> | Subject | Re: why are some atomic_t's not volatile, while most are? |
| |
On Wed, 8 Aug 2007, Chris Snook wrote:
> Jerry Jiang wrote: > > On Wed, 08 Aug 2007 02:47:53 -0400 > > Chris Snook <csnook@redhat.com> wrote: > > > > > Chris Friesen wrote: > > > > Chris Snook wrote: > > > > > > > > > This is not a problem, since indirect references will cause the CPU to > > > > > fetch the data from memory/cache anyway. > > > > Isn't Zan's sample code (that shows the problem) already using indirect > > > > references? > > > Yeah, I misinterpreted his conclusion. I thought about this for a while, > > > and realized that it's perfectly legal for the compiler to re-use a value > > > obtained from atomic_read. All that matters is that the read itself was > > > atomic. The use (or non-use) of the volatile keyword is really more > > > relevant to the other atomic operations. If you want to guarantee a > > > re-read from memory, use barrier(). This, incidentally, uses volatile > > > under the hood. > > > > > > > > > So for example, without volatile > > > > int a = read_atomic(v); > > int b = read_atomic(v); > > > > the compiler will optimize it as b = a, But with volatile, it will be forced > > to fetch v's value from memory > > again. > > > > So, come back our initial question, > > include/asm-v850/atomic.h:typedef struct { int counter; } atomic_t; > > > > Why is it right without volatile? > > Because atomic_t doesn't promise a memory fetch every time. It merely > promises that any atomic_* operations will, in fact, be atomic. For example, > posted today: > > http://lkml.org/lkml/2007/8/8/122
i'm sure that, when this is all done, i'll finally have an answer to my original question, "why are some atomic_t's not volatile, while most are?"
i'm almost scared to ask any more questions. :-)
rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page ======================================================================== - 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/
| |