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

[Robert Munyer]

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
CCL developers.

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.