The keys to a true multithreaded RTOS kernel:

#1 Hardware interrupt driven, based on time slice timer e.g. 10 millisecond.

#2 Kernel array of Task structs for each thread/task.

#3 Task struct contains the current Stack Pointer, SP, of the task as well as full context e.g. CPU registers. The task's SP is used to restore context when switching to the task and the last step to switch to the task is RTI instruction which loads the Program Counter, PC, from the stack. When the task, call it Task A, is switched out in the task switch timer interrupt (see #1), the PC is automatically placed on the stack by the interrupt, and inside the interrupt handler, you store the remaining context (e.g. registers) also on the stack. The secret sauce here is that the PC on the stack is where Task A was running when interrupted. Lo and behold, it's not's your ordinary interrupt handler because other tasks can be switched to, each interrupt cycle, before the kernel logic determines when Task A should be switched back to. And when that time comes, viola, the RTI sets the PC for Task A to continue running where it left off. An ironic aspect (in a good sense) is that the kernel task struct doesn't need to store the PC. It only needs to store the SP, and the interrupt and later RTI manages the PC automatically.

Note: The Task data block (using struct as general term from C) can contain some Task state/context as well as Task control (e.g. priority, suspended) but the stack can also be leveraged for context such as CPU registers. It's a design decision, but generally the stack is a good place for most register context e.g. using any available CPU PUSH/POP instructions for registers.

The key is to store the registers and other context when a task is switched out and restore the context when the task is switched back to.

The SP register and other particular registers that are used for the task switch process itself are handled as special cases for context save/restore (e.g. the SP would be in the Task struct).