Interprocess Locking / Atomic Operations Issue

For any architecture with MMU:

The non-pthreadlib libc operations (inter-process rather than inter-thread communication) should not do user-space locking in any way, as different processes have different address spaces and this can't work. Only pthreadlib might use atomic operations in user space in combination with the FUTEX system calls.

NIOS:

The NIOS Processor does not support any atomic instructions and no cache-sync mechanism, so Hardware-atomicness (e.g. for multiple processors) is not possible, but with using dedicated hardware semaphores (such design is provided by Altera, you need to implement an instance for each semaphore).

Software-Atomicness in Kernel space can be (and is, AFAIK) achieved by temporarily disabling the interrupt.

Thread-atomicness in a non-MMU system (e.g. for doing a FUTEX) can be achieved by temporarily disabling the interrupt.

Thread atomicness in user space with MMU enabled systems (e.g. for doing a FUTEX) can be achieved by implementing an "atomic region" mechanism in the Kernel. But AFAIK, this is not yet done for NIOS. (It is available e.g. for the BlackFin processor and can be done for NIOS in a similar way.)

AFAIK, the usual Interprocess locking system calls are provided as usual.

The GLIBC pthreadlib MUTEX function only uses FUTEX (and thus atomic instructions in user space) when the system, libc is compiled for, does support FUTEX. As with the current NIOS implementation, FUTEX is not supported, it would be an error if libc would try to use it. It needs to fall back to using the (in average much slower) Kernel MUTEX calls instead.

-Michael