I read a few ISRs, which seem to test ulPortYieldRequired alone to determine if it should continue to do task switch, for example, in Source\portable\GCC\ARM_CA9\portASM.S:
So my understanding is, task switch actually happens here, portSave_Context and portRESORE_CONTEXT will still run. But the task switched out and task switched in are the same one (the one interrupted by the interrupt). Is my understanding correct? Shall we test both uxSchedulerSuspended and ulPortYieldRequired to determine which way (exit_without_switch or switch_before_exit) to go in the ISR? The current code works fine functionally, just may do unnecessary context switch.
It would be a little more involved than that. After checking if ulPortYieldRequired was non zero the assembly code would have to check to see if the scheduler was suspended - if not call carry on as now, if so set xYieldPending to 1 (pdTRUE). That would need to be done in each port. If the implementation of the scheduler were to change, each port would need to be updated and re-tested (and there are some 40+ ports).
Thanks, @rtel. I didn’t mean to change the kernel to fix this. I thought we could avoid the unnecessary context saving and restoring by checking uxSchedulerSuspended in the ISR, which is part of the portable layer. You agree on this per your reply, right?
Yes it could be done, just pointing out it is not as simple as just not performing the context switch if the scheduler is suspended, but it is more of an “if( suspended ) do one thing, else perform context switch.”
