<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Sorry to bring up this issue again, as it has been discussed before, and nobody has had any luck solving it.</div><div class=""><br class=""></div><div class="">In short, it is known that ccl (ie, armcl) fails on the Raspberry PI when running threads.</div><div class=""><br class=""></div><div class="">I've been examining with it a bit more, and have maybe narrowed it down a bit, but now I'm stuck.</div><div class=""><br class=""></div><div class="">It seems to me that threads get their locks stolen from them.</div><div class=""><br class=""></div><div class="">A test case is here: <a href="https://github.com/jetmonk/openmcl-thread-test" class="">https://github.com/jetmonk/openmcl-thread-test</a></div><div class="">Running (threadtest2) triggers a modified with-lock macro that grabs a lock, checks that the current process</div><div class="">in fact owns it, runs body, and again checks for ownership before releasing. After many iterations, an error is </div><div class="">thrown when the macro discovers that some other process stole the lock.</div><div class=""><br class=""></div><div class="">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 </div><div class="">mutexes elsewhere online, like </div><div class=""><a href="https://stackoverflow.com/questions/42698277/arm-cortex-m4-mutex-lock-dmb-instruction" class="">https://stackoverflow.com/questions/42698277/arm-cortex-m4-mutex-lock-dmb-instruction</a> </div><div class="">Apparently the issue is different cores not realizing another core has changed memory until (DMB) forces synchronization.</div><div class=""><br class=""></div><div class="">But I tried stuffing (dmb) everywhere in ARM/arm-misc.lisp and it didn't fix the problem. </div><br class=""><div class="">Does anyone have any insights that might help?</div><div class=""><br class=""></div><div class="">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?</div><div class="">Does it happen for ARM64 as well? (which I don' have).</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>