Theoretical remark regarding mutex in the STM32 port
Function pyb_mutex_lock(.) may be unreliable. The execution context switching is performed by setting the interrupt request flag PendSV. In the manuals of the processor do not defined the processing time for this request. In asynchronous machines, with a cache, there is no guarantee that the interruption will occur on the next instruction, after executing the instruction for setting the request flag, even with the highest priority. In addition, this may depend on the implementation of the version of the hardware. Perhaps it would be better to use the SVC instruction for confident context switching. Pay attention to this, please.
rp2/pendsv.c: PendSV_Handler dispatch check.
If MICROPY_PY_THREAD is set, PendSV_Handler acquires a mutex and calls the dispatch functions. If pendsv_schedule_dispatch is called by a higher priority interrupt while the mutex is acquired by PendSV_Handler it's possible for the dispatch to not be triggered.
Add a check for dispatch calls at the end of PendSV_Handler once the mutex has been released.
Fixes #18365
Summary
If an IRQ - that uses the dispatch mechanism - goes off while the pendsv interrupt has its mutex acquired, it stops the dispatch function happening. Fix is to just check if any dispatch functions need to be called after releasing the mutex.
Testing
This change resolves the issue I was seeing (on a port in development)
Ran all tests / Wifi still works!
Trade-offs and Alternatives
There's a small possibility that dispatch functions will be called more than needed.
The new check for dispatch functions may itself be blocked if another thread manages to call pendsv_suspend, but they will be serviced when pendsv_resume is called