ISR versions of mutex_try_enter and mutex_exit

[daveythacher]

#1453 Extends mutex API to support holding the spin lock. This can be used to prevent deadlock from competing core.

[daveythacher]

Note this does cause possible priority inversion, if used incorrectly.

[daveythacher]

Does disabling interrupts on core 1, disable them on core 0? This patch does not cover the case of core 0 ISR and core 1 ISR racing against each other. In which case the patch is not worth much. (Even though this is horrible practice.) This would be new behavior and is capable of creating an issue like 1453. Perhaps documentation could describe the differences between the ISR and non ISR version and which is correct for certain contexts.

Note the ISR version is capable of creating a slight blocking behavior in non ISR version, which may need to be documented. I do not believe this diminishes this request, however does ask a larger question about the SDK.

[daveythacher]

See #1580

[daveythacher]

Note a queue makes more sense.

Edit:
I planned two things but only did one. This was originally done to prevent a race condition. The other change was to allow a try API, which I never added. This version would not use spin_lock_blocking. Overall this API change is questionable.

So I changed the mechanics and forgot to look at the request summary. Overall the symbol names need to be updated in the request. However I knew this would never make it thru. As it does not make sense on SMP. The second change is SMT feature, while the first is a correction for SMP RTOS.

Overall recommendation is ISRs using CPU affinity with short ISRs to notify tasks. Using critical sections within mutex is a finer point that was lost. My displeasure with SDK maintainers is becoming more apparent.

Edit 2:
What this issue actually does is takes ownership of the mutex. (It does not release the spin lock.)

[kilograham]

if you want a mutex which holds the spin lock, use critical_section