Should PendSV_Handler be run synchronously during osKernelResume?

[kjbracey]

Raising this issue for discussion, following this Mbed OS issue:

ARMmbed/mbed-os#11545

When waking from deep sleep, the wake may take a significant time (multiple ticks worth).

Often when resuming, we will be resuming due to activity - eg an ISR signalling a semaphore.

What should happen in this case?

• osSemaphoreAcquire(10)
• System idles waiting for semaphore to be available - osKernelSuspend
• System woken by ISR that releases semaphore
• By the time we get into tick compensation in osKernelResume, semaphore timeout has already passed, due to (unexpected?) wake latency

At the minute, the acquire will fail with a timeout - osRtxThreadDelayTick times out the wait, and the postprocessing for the semaphore release only happens as we wake the thread for the timeout error.

Would it be better to empty the ISR queue first by running the PendSV handler, before running through the thread delay list? That would guarantee that any RTOS op from ISR that made us wake is processed.

[JonatanAntoni]

Hi @kjbracey-arm,

thanks for raising this one. At the first glance this seems a bit odd to me.
I guess we need to carefully review the wake up process.

Cheers,
Jonatan

[kjbracey]

The assumption here is that the ISR signalling the semaphore occurs shortly before the 10ms time is up, say at 8ms, but it takes 3ms to do the wake.

Ideally the HW sleep routine should have allowed for wake latency on the timing, so it should have scheduled a timer IRQ for a few milliseconds before 10ms to give it time to spare. If that worked it should have been woken by a timer IRQ from 7ms, say, giving it time to also deal with the semaphore ISR and resume and postprocess it before passing tick 10.

But it appears in our test that has failed to happen, at which point the wake process appears to prioritise timer expiries above pending ISRs during the catch-up.

[JonatanAntoni]

Hi @kjbracey-arm,

I discussed the issue in details with the development team. Unfortunately we came to the conclusion that we won't be able to get rid off the race condition, completely. As any solution leads to some sort of compromise we would like to stay with the current implementation.

Cheers,
Jonatan