Quote:
Originally Posted by Mark McLeod
The parallelism of the two tasks within the loop task has to be taken into account: The loop task starts
The timer task starts and goes away for 5ms
The 1ms task starts and finishes, then it too goes away
The loop task rests as all it's internal tasks are not yet satisfied, but it has nothing to do
The CPU wakes up the loop task when the 5ms timer expires
The loop task sees that all it's tasks are accomplished and moves on
The timer task only stops itself. It doesn't stop tasks around it. It really sets a timer interrupt.
If the Timer task expires and the loop task is still active because of other independent tasks within it the CPU doesn't have to wake it up and it doesn't get scheduled. |
I've been reading and re-reading the above post and I think I may have had an epiphany.
Is this any closer to the truth:
- the 5ms periodic vi has two parallel "tasks" in it: a 5ms timer, and some code that takes 1ms to execute
- this 5ms periodic vi gets called once to kick-start it
- the first time the 5ms periodic vi gets called, the CPU encounters the 5ms timer task and executes that... which basically just sets a timer interrupt to occur 5ms in the future.
- the CPU comes back and starts executing the 1ms "task", and finishes it.
- since the 5ms timer task hasn't finished yet, the 5ms periodic vi can't "finish". The CPU goes and does something else.
- when the 5ms interrupt occurs, this basically completes the 5ms timer "task", so the periodic vi is now "finished"
- in this scenario, it
is required to make the periodic vi loop back and start again
Is the above even remotely correct?
~