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).

TL;DR: RTOS is not about multitasking, it's about scheduling.

What you describe here is just plain good old multitasking, and not RTOS (assuming you mean real-time operating system).

Again, this has nothing to do with RTOS and/or multitasking, this is called ticking / tickless kernel.
- When you do an interrupt at precise intervals, then your kernel will have "ticks". Easier to implement but you'll loose performance (you'll have to handle the interrupt even when it does not trigger a task switch).
- If you dynamically program your timer to do an interrupt when the task's time slice runs out, that's called a "tickless" kernel. Harder to do it right, but this is what all modern OS kernels do.

In an RTOS, tasks are never interrupted, they yield after their precisely calculated time slice (known to the kernel as well as to the task) runs out.

What RTOS really means is, that you can calculate the time slices in advance for each task, so that you can predict how tasks will be scheduled, therefore you'll be able to run a task at an exact time.
- If you can always guarantee that a task will be scheduled at the requested time, then you have a hard real-time kernel.
- If it's possible that a task might miss its deadline, then that's called a soft real-time kernel.

As you can see, the thing that makes an RTOS is mostly about scheduling and timing tasks, and not about how the task switching is actually implemented. See Criteria for real-time computing.