Re: Using __kuser_cmpxchg

[Nicolas Pitre <nico at cam dot org>]

On Thu, 15 Nov 2007, Andrew Haley wrote:

> These are threads in the Java sense, not in the POSIX sense.
> 
> Each thread has a permit.  
> 
> "A call to park will return immediately if the permit is available,
> consuming it in the process; otherwise it may block. A call to unpark
> makes the permit available, if it was not already available. (Unlike
> with Semaphores though, permits do not accumulate. There is at most
> one.)
> 
> "Methods park and unpark provide efficient means of blocking and
> unblocking threads that do not encounter the problems that cause the
> deprecated methods Thread.suspend and Thread.resume to be unusable for
> such purposes: Races between one thread invoking park and another
> thread trying to unpark it will preserve liveness, due to the permit."
> 
> http://java.sun.com/javase/6/docs/api/java/util/concurrent/locks/LockSupport.html
> 
> Java threads can be in three states, PARKED, RUNNING, and PERMIT.
> When unpark() is called, we do this:
> 
>   /* If this thread is in state RUNNING, give it a permit and return
>      immediately.  */
>   if (compare_and_swap
>       (ptr, Thread::THREAD_PARK_RUNNING, Thread::THREAD_PARK_PERMIT))
>     return;
> 
>   /* If this thread is parked, put it into state RUNNING and send it a
>      signal.  */
>   if (compare_and_swap
>       (ptr, Thread::THREAD_PARK_PARKED, Thread::THREAD_PARK_RUNNING))
>     {
>       ...
> 
> To get back to ARM's __kuser_cmpxchg: if this second compare_and_swap
> fails spuriously we won't unblock the thread.

Hmmm...

Of course the primary usage for __kuser_cmpxchg was to be used in the 
implementation of some routines like atomic_add where cmpxchg is 
attempted repeatedly until it succeeds.

I think there is a way to get rid of the possibility for false 
negatives, but I want to think about it some more.

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.


Nicolas