Using __kuser_cmpxchg

Fri Nov 16 01:24:00 GMT 2007

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