Quote:
Originally Posted by Mark McLeod
The parallelism of the two tasks has to be taken into account: The timer task goes away for 5ms
The 1ms task finishes, then it too goes away
The loop rests as all it's tasks are not yet satisfied
The CPU wakes up the loop when the 5ms timer expires
The loop sees that all it's tasks are accomplished and moves on |
My understanding of the timer has completely changed based on the above. It is not a timer, per se, but rather a mechanism to re-schedule the present task at a future time...
So it looks like this (assuming the 5ms task is the only task in the system):
- at t=0 the CPU encounters the 5ms timer which re-queues the task to run again at t=5ms (or as soon thereafter as possible)
- the CPU then
continues on in the task to execute the task's code, which takes 1ms.
- the task is finished; it is now t=1ms. the CPU goes idle until t=5ms
- at t=5ms, the scheduler gets the task from the queue and runs it again
Is the above correct? If so, then the user, when coding a periodic task, should NOT put the task in an infinite loop, as my original pseudo-code did. Instead, the task should be coded as a one-shot, because the timer vi re-queues it each time it is run. Correct?
~