Contextual switching to preventive, monolithic, multi-tasking operating systems includes one of two ways: either implicit income for the scheduler through some call to the system service (sleep, receiving a mutex, waiting for an event, blocking I / O), or through an interrupt and a scheduler deciding exchange of current tasks.
When a task is replaced by a scheduler, several tough things happen:
- All actions are performed as part of the kernel of the operating system, operating with a high level of privileges. Each action is checked (or should be) to ensure that decisions made by the scheduler do not provide the task with any additional privileges (think about using a local root)
- User mode address spaces are replaced. This leads to the fact that the memory manager twitches with the layouts of the page tables and loads the new directory database into the management register.
- It also means that data stored in the CPU cache can be dropped and deleted. It would suck if your task had just gained access to a bunch of commonly used materials, then the context switched and “lost” it (the next time it accessed, it probably should have been extracted from main memory again)
- Depending on how you get into the kernel, you need to catch OUT from the kernel. For example, if you make a system call, the CPU will perform a very accurate set of steps to go to the code running in the kernel, and then, when exiting, cancel these steps. These steps are more complicated than calling a function for another module in your program, so they take longer.
The green thread task is pretty simple, as I understand it. The user mode dispatcher directs the coroutine to execute before receiving the coroutine. A few differences above:
- None of the coroutine mailing runs in kernel mode, so sending green threads usually does not require any operating system services or any blocking operating system services. Thus, all this can happen without any context switches or any user / kernel translation.
- The green thread is not assigned in advance or is not unloaded at all by the green thread manager, they are planned together. This is good and bad, but with well-written procedures, they are usually good. Each task performs exactly what it needs to do, and then the trap is returned to the dispatcher, but without any changes to the context swap.
- Green threads exchange their address space (as far as I know). Address space permutation does not occur when switching contexts. Stacks (as far as I know) are swapped, but these stacks are controlled by the dispatcher, and replacing the stack is a simple register entry. Switching the stack is also an unreliable operation.
In short, a context switch in user mode involves several library calls and writing to the stack pointer in the register. The kernel mode context switch includes interrupts, user / kernel transitions, and system-level behavior, such as changes in the address space state and cache flushing.