On cortex-m23, tasks might fail to schedule properly #1151
Description
When is the issue relevant:
When target is m23 and the interrupt control bits fall on two or more control registers.
What is the bug
Interrupts are not disabled atomically. M23 has more than 32 interrupt handlers, but it has no BASEPRIO and disables interrupts individually.
Example situation where the bug occurs
Assume there are tasks t1, ..., t3, t4. Assume t1 has lowest priority, t3 the second highest priority and t34 the highest priority. Assume t1 and t3 access a resource R, and t4 does not access the resource R. Assume control bits for t3 and t2 fall on different control registers.
Assume t1 is running and is about the take a lock on the resource. This means we need to disable tasks t1-t3. We can not disable t2 and t3 at the same time, so one or the other is disabled first. If t3 is disabled first, t2 might preempt right after that. Assume t3 arrives when t2 is running. Now, t3 has to wait more than the SRP guaranteed "one critical section of one lower priority task".
Notice there might not be a problem if the interrupts are disabled in an increasing order of priority. Notice also, that the delay might be even biffer if there are more tasks.
Suggested solution
Disable the interrupts inside a CS. It could be a conditional compilation on the thumbv8m.base-none-eabi target. Some analysis is warranted to figure out if the addition of the CS could be avoided and compiled with more conditions.