enhance k_mutex to be ISR safe

[andrewboie]

Is your enhancement proposal related to a problem? Please describe.
We currently forbid k_mutex APIs in ISRs, due to the way the code assumes that the operation is on the behalf of _current. In an ISR, _current is just the thread that was running when the ISR fired, it should have no basis in the logic of the lock/unlock operations.

Describe the solution you'd like
Per @andyross we may be able to allow this with some work:

we could allow a k_mutex to be used in an interrupt. Semaphores work in interrupts.

The rules about priority inheritance get complicated but are still tractable. You obviously can't adjust the current thread priority in an ISR, but you don't really need to: the interrupt is already as "maximum priority" and can't be boosted, and it won't be reprioritized downward because that would be trying to reset it's "original" priority, which has to be "interrupt" or else there's a lock nesting violation somewhere.

Similarly ISRs won't block (timeout must be K_NO_WAIT, a-la k_sem_take()), so you don't have the problem of trying to elevate the priority of a thread to "interrupt".

There are probably edge cases and some subtle bugs involved in trying to do that, but it could be done.

Describe alternatives you've considered
None yet.

[andrewboie]

Might be worth reviewing https://www.kernel.org/doc/html/latest/locking/rt-mutex-design.html as we look to refactor k_mutex.

[andrewboie]

By the way before we do this, I would like to see some examples of precedent in other RTOSes. This really seems an odd use-case to me.

[pabigot]

More context: An existing proposal for a simple mutex that could handle some use cases is #8496. #26073 suggests the full mutex be used because of priority inheritance (which should allow a high priority thread to get access to a resource it needs faster).

[nashif]

#8496 would not give you the priority inheritance feature, it will just wrap current semaphores.
emphasizing what @andrewboie says above, I do not see any precedent for this anywhere and it might make things more complex than they should be, for #26073 we should look for a different solution.

[nashif]

Based on the discussion above, we should not pursue this.