Hi,
roughly how many instructions does it take to do a complete task context switch? I know it depends on the micro etc. But roughly, are we talking about 10-15 or 50-100?
If only 10 or so, it is not that relevant to my question. But if longer, then what happens if an ISR (which then notifies a higher priority task) occurs in the middle or at the beginning of a context switch?
I assume the ISR executes immediately interrupting the previously running context switch. But does freeRTOS then goes back to complete the first context switch and then does the second context switch to run the higher-priority task?
Or does the higher priority task run immediately after the ISR leaving the previous context switcing “dangling” half way through until freeRTOS goes back to it later when exiting the higher priority task?
I am asking because if the context switch takes 50-100 instructions then the two scenarios described above could cause quite a different in latency in executing the high-priority task.
At all places in the kernel, including the context switch, there will be a critical section (preventing interrupts that can cause a context switch) if there is a chance of a task’s context getting corrupted.
cannot work out the cycles for a “normal” context switch (i.e. not through a notification - if it is relevant, which I don’t think is the case).
How many instructions does it take? On platform like a PIC32 - if you are familiar with it - or any other 32bit MIPS architecture (which is not RTOS optimised).
The total turnaround for a context switch actually consists of two parts - first (if induced by a signal) the “give” or “notify” logic, then the switch itself. The costs for the switch can normally be deduced from the porting layer (in most cases, it’s written in Inline assembly, so you’d need to simply count the instructions).
The trigger logic can be quite significant depending on a number of factors such as platform, optimization and which trigger mechanism is used. If I recall correctly, we once had severe problems getting fast enough turnaround through semaphores. That was back in the days of FreeRTOS 7 or 8 before notifications were introduced. I remember that one of the primary reasons WHY they were introduced was this very issue; initially they were labelled something like “lightweight semaphores” if I recall correctly.
As @richard-damon pointed out, the most reliable way to figure this out is through cycle counters. I’m not familiar with your target platform, but what you can possibly do if you don’t have access to one is start off a free running hardware timer right before you enter the trigger logic and read the timer right after the tasked switched into wakes. The Delta will give you a fairly reliable metric for your switch costs.
