Coldfire __lll_lock fails under heavy system stress

[Ed Slas <ed_slas at yahoo dot com>]

I have been able to show that low level locks do not work properly on coldfire CPU.


Under heavy system stress with an application that uses real time threads, The low level lock implementation fails with several symptoms. 
I have a test app that creates 40 RT threads, each thread mallocâing 500 bytes, filling it and checking it was filled a million times. 
While this is running, one of a couple things will fail:
-A thread will stop running, waiting on a lock that no one holds.
-segmentation fault
-glibc bails complaining about corrupted double-link lists. 


ports/sysdeps/unix/sysv/linux/m68k/nptl/lowlevellock.h
uses
atomic_compare_and_exchange_val_acq
to implement locks. 
For coldfire, atomic_compare_and_exchange_val_acq is implemented in ports/sysdeps/unix/sysv/linux/m68k/coldfire/nptl/bits/atomic.h
with the system call
atomic_cmpxchg_32

I rarely delve this low into the code, so I cannot explain why this implementation fails, but it is very suspicious that the kernel (2.6.38) interrupt handler repositions the PC if it sees the PC at interrupt was in atomic_cmpxchg_32(). 

In a effort to work-around my problem, I wrote a user-space lock using the m68K TAS instruction. This instruction only works on a bit, so I could not implement the âwaitersâ condition, where the futex is changed from 1 to 2. 
With the lack of the waiters condition, I simply call FUTEX_WAKE for every unlock. 

Using these modifications, I was able to run my test app successfully and ultimately my real application no longer exhibits these issues. 

Not being a maintainer, I do not have the wherewithal to submit a patch. However, I am willing to work with anyone if interested to get this fixed in the m68k/coldfire port. 

Anyone interested?

-Ed