RE: Using __kuser_cmpxchg

["Boehm, Hans" <hans dot boehm at hp dot com>]

FWIW:  The C++ atomics library that was recently voted into the C++
working paper
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html )
allows "spurious" "compare_swap" failures, and returns both the read
value, and
whether or not the CAS succeeded.  It would be nice if the kernel
interface
allowed that to be implemented as efficiently as possible.

Hans

 

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of Nicolas Pitre
> Sent: Friday, November 16, 2007 6:32 AM
> To: Paul Brook
> Cc: linux-arm-kernel@lists.arm.linux.org.uk; Andrew Haley; 
> java@gcc.gnu.org
> Subject: Re: Using __kuser_cmpxchg
> 
> On Fri, 16 Nov 2007, Paul Brook wrote:
> 
> > > > > On a pre-ARMv6 processor
> > > >
> > > > Similar "spurious" failures can happen on ARMv6 processors.
> > > >
> > > > ARMv6 cpus don't have atomic operations either. They have 
> > > > ldrex/strex, where the latter will fail if another CPU modifies 
> > > > the memory *or* a context switch occurs.
> > >
> > > Due to the current implementation this is indeed true.
> > >
> > > ARMv6 is more trivial to fix though, since the operation can be 
> > > reattempted whenever the strex fails.
> > 
> > I'm confused. Why is this any different to ARMv5? AFAICS the two 
> > kuser_cmpxchg implementations are functionally equivalent.
> 
> Yes they are.  My point is that fixing the ARMv6 one to 
> eliminate the false negative is almost trivial.  The 
> pre-ARMv6 is not so trivial though.  And I don't want to 
> change the interface of course.
> 
> I implemented a fix here but I still want to think it through 
> so not to miss some implications wrt page faults for example.
> 
> 
> Nicolas
>