How a context switch works in a RTOS, need clarity

Question

im wondering whether I understand the concept of a RTOS, and more specifically the scheduling process, correctly.

So, I think I understand the process of a timer interrupt (i omitted the interrupt enable/disable commands for better readability here)

1. program runs...
2. A timer tick occurs that triggers a Timer Interrupt
3. The Timer ISR is called
    The timer ISR looks like this:
    3.1. Kernel saves context (registers etc.)
    3.2. Kernel checks if there is a higher priority task
    3.3. If so, the Kernel performs the context switch
    3.4. Return from Interrupt
4. Program runs with another task executing   

But how does the process looks like, when an Interrupt occurs from lets say a I/O Pin?

1. program runs
2. an interrupt is triggered because data is available
3. a general ISR is called?
    3.1. Kernel saves context
    3.2. Kernel have to call the User defined ISR, because the Kernel doesn't know what to do now
        3.1.1 User ISR runs and does whatever it should do (maybe change priority of a task, that should run now, because the data is now available)
        3.1.2 return from User ISR
    3.3. Kernel checks if there is a higher priority task available
    3.4. If so the Kernel performs a context switch
    3.5. Return from Interrupt
4. program runs with the different task

In this case the kernel must implement a general ISR, so that all interrupts are mapped to this ISR. For example (as far as i know) the ATmega168p microcontroller has 26 interrupt vectors. So there should be a processor specific file, that maps all the Interrupts to a general ISR. The Kernel-ISR determines what caused the interrupt and calls the specific User-ISR (that handles the actual interrupt).

Did I misunderstood something? Thank you for your help

Answer 1

There is a clear distinction between the OS tick interrupt and the OS scheduler - you have however conflated the two. When the OS tick ISR occurs, the tick count is incremented, if that increment causes a timer or delay expiry, that is a scheduling event, and scheduling events causes the scheduler to run on exit from the interrupt context.

Different RTOS may have subtle differences, but in general in any ISR, if a scheduling event occurred, the scheduler runs immediately before exiting the interrupt context, setting up the threading context for whatever thread is due to run by the scheduling policy (normally highest priority ready thread).

Scheduling events include:

• OS timer expiry
• Task delay expiry
• Timeslice expiry (for round-robin scheduling).
• Semaphore give
• Message queue post
• Task event flag set

These last three can occur in any ISR (so long as they are "try semantics" non-blocking/zero timeout), the first three as a result of the tick ISR. So the scheduler will run on exit from the interrupt context when any interrupt has caused at least one scheduling event (there may have been nested or multiple simultaneous interrupts).

Scheduling events may occur in the task context also including on any potentially blocking action such as:

• Semaphore give
• Semaphore take
• Message queue receive
• Message queue post
• Task event flag set
• Task event flag wait
• Task delay start
• Timer wait
• Explicit "yield"

The scheduler runs also when a thread triggers a scheduling event, so context switches do not only occur as the result of an interrupt.

To summarise and with respect to your question specifically; the tick or any other interrupt does not directly cause the scheduler to run. An interrupt, any interrupt can perform an action that makes the scheduler due to run. Unlike the thread context where such an action causes the scheduler to run immediately, in the interrupt context, the scheduler is deferred until all pending interrupts have been serviced and runs on exit from the interrupt context.

For details of a specific RTOS implementation of context switching see §§3.05, 3.06 and 3.10 of MicroC/OS-II: The Real Time Kernel (the kernel and the book were specifically developed to teach such principles, so it is a useful resource and the principles apply to other RTOS kernels). In particular Listings 3.18 to 3.20 and Figure 3.10 and the associated explanation.