Calling vTaskSuspend() on both cores can result in lost ticks (IDF-183)

[projectgus]

Originally reported by @ourairquality here:
#1400 (comment)

I'm able to reproduce the issue as follows:

• Both cores call vTaskSuspendAll() (in either order)
• More than one tick interrupt passes (causing uxPendedTicks to be non-zero)
• Core 1 calls xTaskResumeAll() before Core 0 (causing uxPendedTicks to be zeroed without the tick count incrementing)

I believe all three conditions are required for the bug.

The tick count is lower than it should be, compared to the passage of time. This causes timeouts to occur later than they should, and using the tick count for wall time measurements will be inaccurate.

@ourairquality, please let me know if this matches the circumstances you're seeing.

AFAIK it's not very common to disable scheduler on both cores for extended periods (rather than using critical sections), which I think is probably why this hasn't been noticed until now. However we will fix obviously fix it!

[ourairquality]

Thank you. It might be far more common as it appears that accessing the flash, via spi_flash_read() etc results in both cores calling vTaskSuspendAll(). It probably requires a tick interrupt to occur on Core 0, but that seems likely. It is then a race to see which core calls vTaskSuspendAll() first. A workaround for that path might be possible in spi_flash_enable_interrupts_caches_and_other_cpu() - have Core 1 spin until Core 0 has resumed, but that would not address the issue in general.

[projectgus]

Yes, you're right about spi_flash access. Good point, thanks.

[X-Ryl669]

Could the problem be solved by having each core deal with its own uxPendingTick (without interfering with the other) ?

[ourairquality]

Nice to see a fix, thanks. Looking at the patch it appears that vApplicationTickHook() is not called now when processing the pended ticks, that code has been removed. Might that cause a loss for an app that had a hook to be called once for each tick, that counted them. I don't use that hook, just questioning if calling that hook could be usefully retained. If would appear that keeping that code could result in that hook being called from core 1, rather than core 0 in the common paths, and was that a problem and the reason this code was removed?