[Openmcl-devel] RPi arm failures in locking and threading

[JTK]

Sorry to bring up this issue again, as it has been discussed before, and nobody has had any luck solving it.

In short, it is known that ccl (ie, armcl) fails on the Raspberry PI when running threads.

I've been examining with it a bit more, and have maybe narrowed it down a bit, but now I'm stuck.

It seems to me that threads get their locks stolen from them.

A test case is here:   https://github.com/jetmonk/openmcl-thread-test <https://github.com/jetmonk/openmcl-thread-test>
Running (threadtest2)  triggers a modified with-lock macro that grabs a lock, checks that the current process
in fact owns it, runs body, and again checks for ownership before releasing.    After many iterations, an error is 
thrown when the macro discovers that some other process stole the lock.

I thought it might be a lack of ARM DMB instructions ("ensures that all memory accesses are completed before new memory access is committed.")  in atomic routines , which have been discussed as necessary for ARM 
mutexes elsewhere online, like   
https://stackoverflow.com/questions/42698277/arm-cortex-m4-mutex-lock-dmb-instruction <https://stackoverflow.com/questions/42698277/arm-cortex-m4-mutex-lock-dmb-instruction>  
Apparently the issue is different cores not realizing another core has changed memory until (DMB) forces synchronization.

But I tried stuffing (dmb) everywhere in ARM/arm-misc.lisp and it didn't fix the problem. 

Does anyone have any insights that might help?

Also, this all happens because this is compiled with #-futex, yet the RPi seems to support futexes natively, if I understand it correctly.   Would these issues happen for all CPUs where #-futex is used, or just ARM32?
Does it happen for ARM64 as well? (which I don' have).

Again, apologies if I'm beating a dead horse, but ccl is the only good lisp that can run on RPi.   SBCL is heavy, and lacks 32 bit threading.    ECL (imho) just isn't at the same quality as ccl and SBCL.   


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20220528/7e38f498/attachment.htm>