Jan Engelhardt wrote:
On Aug 7 2007 15:38, Chris Friesen wrote:
That volatile is there precisely to force the compiler to dereference it every single time.
Actually, the dereference will be done once (or more often if registers are short or the compiler does not feel like keeping it around), and the read from memory will be done on every iteration ;-)
My bad. You are, of course, correct. :) Chris - 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/
- References:
- why are some atomic_t's not volatile, while most are?
- From: "Robert P. J. Day" <[email protected]>
- Re: why are some atomic_t's not volatile, while most are?
- From: Jerry Jiang <[email protected]>
- Re: why are some atomic_t's not volatile, while most are?
- From: Chris Snook <[email protected]>
- Re: why are some atomic_t's not volatile, while most are?
- From: "Chris Friesen" <[email protected]>
- Re: why are some atomic_t's not volatile, while most are?
- From: Chris Snook <[email protected]>
- Re: why are some atomic_t's not volatile, while most are?
- From: "Chris Friesen" <[email protected]>
- Re: why are some atomic_t's not volatile, while most are?
- From: Chris Snook <[email protected]>
- Re: why are some atomic_t's not volatile, while most are?
- From: "Chris Friesen" <[email protected]>
- Re: why are some atomic_t's not volatile, while most are?
- From: Jan Engelhardt <[email protected]>
- why are some atomic_t's not volatile, while most are?
- Prev by Date: [RFC][PATCH] uli526x: Add suspend and resume routines (updated)
- Next by Date: Re: [PATCH/RFT] finish i386 and x86-64 sysdata conversion
- Previous by thread: Re: why are some atomic_t's not volatile, while most are?
- Next by thread: Re: why are some atomic_t's not volatile, while most are?
- Index(es):
 |