Messages in this thread | | | Date | Mon, 3 Mar 2008 09:31:57 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [patch] Re: using long instead of atomic_t when only set/read is required |
| |
On Tue, Mar 04, 2008 at 04:16:33AM +1100, Nick Piggin wrote: > On Tuesday 04 March 2008 02:53, Alan Cox wrote: > > > Atomicity of reads of write for pointers and integral types (other than > > > long long) should be documented. > > > > NAK. > > > > Atomicity of reads or writes for pointers and integral types is NOT > > guaranteed. Gcc doesn't believe in your guarantee. > > Are you sure gcc doesn't? Or is it just "C"? > > Linux wouldn't work today if gcc did something non-atomic there > (presuming you're talking about naturally aligned pointers/ints). > It is widely used and accepted. > > RCU users are far from the only places to rely on this, although > I guess they are the main ones when it comes to assigning pointers > atomically.
It is true that gcc can refetch pointers/ints if it runs out of registers, which is why rcu_dereference() recently had an ACCESS_ONCE() added to it.
But such refetching cannot result in a mish-mash of two different pointer values, confusing though it might be to the affected code.
Thanx, Paul
| |