Re: Using __kuser_cmpxchg

[David Daney <ddaney at avtrex dot com>]

Paul Brook wrote:
> > >  > In the mean time you can work around it by using a mutex around the
> > >  > thread state modification instead of using cmpxchg on it.  Or if your
> > >  > platform is ARMv6 or higher then you won't get those spurious false
> > >  > negatives.
> > >
> > > Ah, OK, that's interesting: it sounds like you understand under what
> > > circumstances it may fail "spuriously".
> > Heh, I wrote that code (and comment).  :-)
> >
> > > What are these?
> > 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.

This seems similar to MIPS ll/sc.  Perhaps if the arm port were modeled 
after that.

For MIPS we implemented all the the atomic memory operations in terms of 
the ll/sc primitives, then in the libjava/sysdep/mips/locks.h we use the 
buildins:

inline static bool
compare_and_swap(volatile obj_addr_t *addr,
                 obj_addr_t old,
                 obj_addr_t new_val)
{
  return __sync_bool_compare_and_swap(addr, old, new_val);
}


David Daney