Why timer callback function should never attempt to block?

Kernel
1

jvgediya wrote on Friday, October 06, 2017:

What can be the consequences? Could you please explain with example scenario?

Thanks,
Jags

2

rtel wrote on Friday, October 06, 2017:

All the timer callback functions run in the context of the same timer
task. If one of the callback functions blocks, then the timer task is
blocked. If a timer should expire while the timer task is blocked then
the timer’s callback function is not going to run when it should, but
whenever the timer task leaves the Blocked state.

3

richard_damon wrote on Friday, October 06, 2017:

I would say that ‘Never’ is just slightly too strong a term here (It isn’t like blocking in the Idle Hook which will likely crash your system). A timer hook that blocks, or that takes a lot of time to process, can impact all other timer call backs (and functions pended by an ISR), as they all use a common task to run in. It is possible for a user to understand the implications, and carefully do things that might blocks.

An example where blocking in a timer callback would be a system with timer events with tolerances in the 10s of milliseconds, and the timer callback is going to do an I/O operation that might block for 100s of microseconds. That would be very acceptable, It shouldn’t do a block that might take a 100 milliseconds though.