[Openmcl-devel] RPi arm failures in locking and threading
2420506348 at munyer.com
Tue May 23 15:00:31 PDT 2023
On 28 May 2022, jetmonk wrote:
> A test case is here: https://github.com/jetmonk/openmcl-thread-test
Your use of "taskset" isn't right. You don't need "sudo", and you do need
the "-a" option when you use it on a CCL instance that's already running.
Alternatively, you can pin a CCL instance to a single core _before_ it
runs, by starting it with a command like "taskset 2 ccl".
On my pine64 device, running CCL 1.12.1 on Debian arm64 "testing",
your THREADTEST2 crashes if I run CCL the normal way, but completes
successfully if I run CCL on a single core via "taskset 2 ccl".
> 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).
I think the futex code is disabled on all platforms. Log excerpts:
2013-01-28 We don't want to use futexes (at least not instead of spinlocks.)
2013-01-28 No futexes on LinuxARM, either.
2014-11-27 Don't use futexes on Android, either.
Does anyone know why this was done? My (possibly naive) expectation
is that using futexes would be a good way to let some of the difficult
platform-specific detail work be done by OS developers instead of by
P.S. I'd expect Apple's M1 processor to have this same issue, so, if
the CCL-on-M1 effort succeeds, I'd expect this bug to become trivial.
More information about the Openmcl-devel