CODEWITHSUNDEEP
assemblyx86operating-systemmultiprocessing
AlanCui
AlanCui

Reputation: 157

How is the time-based process management implemented

Excuse me, how is the time-based process management implemented?

How does the cpu switch from the kernel function to the process? How does the cpu switch back?

For example, when the time slice is exhausted, how does the cpu force the conversion back to the kernel function? In the program, there is no switch function compiled, is it an interrupt? I don't quite understand, please answer me if you can

Upvotes: 1

Views: 145

Answers (2)

Erik Eidt
Erik Eidt

Reputation: 26656

Typically, at an interrupt of any kind, some portion of the currently running process' CPU state is saved (into memory).  Some amount of this saving is necessary even to run fairly restricted assembly code, and another portion enables some more normal, maybe C code, to run, possibly part of the device driver stack.  Once the interrupt is serviced, that portion of the process' CPU state is restored and the interrupted process can resume, unaware of the interruption.

During certain interrupts, the OS scheduler may choose to resume a different process from the one interrupted, and if it does, then all the rest of the interrupted process' CPU state is saved, while the process to resume's state is restored into the CPU.  Much of this is done with normal CPU instructions such as write (and read) register to (from) memory.

Switching processes take both extra effort to save & restore the CPU context, but also the processor caches are cold for an alternate process — so the best choice in terms of performance is that the interrupted process is resumed.  However, the scheduler may choose to switch processes (context switch) if, I/O for a higher priority process is now ready to be consumed, or, if the current process has had it's fair share of the CPU, timewise, and there are other equal priority processes to run.

The basic mechanism is called exception handling by hardware engineers, and it covers both software caused exceptions (traps/syscalls, divide by zero) as well as access violations (page faults, null pointer dereferences, copy on write), and device interrupts, which include timers and device or I/O ready signals.  This is an automatic mechanism built into the processor — that it can do the most basic interruption of a running process, and transfer control to the operating system interrupt service routine.

This processor mechanism decides which instruction is uncompleted (i.e. interrupted), and it finishes all prior instructions, cancels all subsequent instructions, then transfers control of the instruction stream to the interrupt service routine, giving it some minimal state about the interrupt, which includes both the reason for the interrupt and the program counter/instruction pointer of the interrupted process, since that is generally wiped out by transferring control to the ISR.  After that, it is software's job to save any additional CPU state of the interrupted process, and handle the exception, whether caused by the running process or externally triggered.  The processor also has an mechanism (an instruction usually called something like return from interrupt) by which it can restore the last bit of state needed to resume a user process, and this can be augmented by software to resume any process.

The division of labor between what hardware saves as the context of the interrupted process and what is software's responsibility varies greatly between processors.  On x86 the hardware saves more context than strictly minimal and this allows some new x86 CPU's to run on operating systems that don't know about them.  On other processors the hardware's function is more strictly minimal and software has to do the rest.

Upvotes: 2

user35443
user35443

Reputation: 6413

There are at least as many ways of handling pseudoparallelism as there are kernels out there.

The most naive student implementation would involve and external interrupt being triggered after the time slice of one process has been used up, possibly by a timer of some sort (on PCs traditionally "PIT", the Programmable Interrupt Timer). The kernel would, at that point, be either implicitly or explicitly put into the privileged mode, save the context (i.e. the contents of the registers and virtual memory information) of the current process, load the context of the old process, change to an "underprivileged" mode (e.g. rings 1-3 on x86-based processors) and finally jump to where the new process had been interrupted in its execution.

Upvotes: 1

Related Questions