A computer is expected to handle many distinct jobs simultaneously. If it is a server, multiple users will be logged in simultaneously, each performing tasks unrelated to the tasks of other users. Besides work on behalf of users, the server will be attending to such housekeeping as logging events, rearranging data on the disk, or listening to requests for service from the network. An individual user’s machine will have multiple tasks associated with the graphics system, such as moving the mouse cursor, redrawing windows as they are resized or iconified, as well as carrying out the user’s requests, or listening to replies to requests it has made to other computers on the network.

Each task is collected into a process. A process is a fundamental abstraction created by an operating system. It roughly represents the running of a single program. Your computer is at times running tens, maybe hundreds of programs, further broken down into threads, lines of control inside a single process.

A modern operating system must be able to run multiple processes at a time. Since there is only a fixed hardware resource on which to run multiple processes, the operating system must create the illusion of replicating the hardware as necessary to run the many processes. The method of time slicing shares the CPU by giving each process a short burst of cycles on the CPU, and rotates through all the processes with sufficient speed to give the illusion that the processes are running simultaneously.

A process includes both a context and a thread of control. The context is all the data in the environment of the program that the program can access and manipulate. It includes its own program, its stack and heap, data structures to access files that the process has opened, the processes permissions and handles for inter-process communication. The thread of control is the additional data, usually the registers in the CPU, that are the mechanical heart of implementing the instruction stream. Originally, each process had exactly on thread of control. More sophisticated styles of programming, particularly event driven programming, required that a process possibly contain multiple threads of control. The term thread was coined, and a process became the combination of a context and threads.

Central to multiprocessing is the ability to change from process to process, the context switch. Associate with each process is a large data structure, the process control block, or PCB, that records all of the data associated with a process. When the PCB is completely filled out, the process can be paused, as its entire state has been recorded. Restoring this state to the thread of control, and restoring any additional registers to reinstall the context, will restart the thread and process from where it was paused. More correctly, since the threads are also being multi-programmed, there is a thread control block, or TCB, associate with each thread, and made dependent on the PCB of the process, and a thread can be paused by moving all pertinent register data from the CPU to the TCB, and later resumed by coping back from the TCB into the CPU registers.

A context switch is demanded by the operating system in order that each process receive its share of the processor. The delivery of cycles to a process must be timely and sufficient: timely in that there is often a limit to the delay that can be tolerated between runs of the process. For instance, the mouse moving routine must be invoked frequently enough that the cursor appear to move smoothly; and sufficient in that enough cycles must be allocated to the process that it keep up with its computational appetite.

A context switch occurs in kernel mode. It is worked into the general syscall mechanism. When a user process enters the kernel because of a syscall or interrupt, the kernel might pause the process rather than return to it. If it does this, it will return to a different process, one that was paused earlier in this same manner. A process might cause a syscall in order to obtain data. Often the data is not immediately available. It might need to be requested from disk, from a network connection, or from a users’ typing commands. This is a perfect opportunity for the process to be paused, to be continued when the data is available.

A program might, however, attempt to run for a long period of time without a syscall. To ensure that each process have its timely and sufficient access to the CPU, most operating systems use preemptive multitasking, and will force the running program to yield the CPU to another process. It is necessary to have a hardware clock that interrupts the processor every so often in order to have preemptive multitasking. An interrupt is similar to a syscall. Both are a form of trap: they cause the running process to jump away from its code to kernel code running in kernel mode; they remember on the stack enough information to return to the interrupted task; the return will reset the processor back to non-kernel mode. However, an interrupt is asynchronous — it pushes its syscall into the instruction stream, so to speak, motivated by an external event. A syscall is synchronous — the syscall appears as an instruction in the instruction stream.

=======+ Process A        +===== Process B            
       |                  ^       
  ---- | ---------------- | ------- user/kernel            
       |   +===schedule===+             
       V   ^     ^  ^              
       +===+     |  |
       ^ ^       |  +---- Context of Process B
       | |       +------- Context of Process A
       | |
       | +- clock sets "need scheduler"
       +--- interrupt

It is the job of a software component called the scheduler to determine which process to choose to replace the current process. Each process is in one of these states: running, runnable, sleeping or deceased. On each return from each syscall or interrupt, the running process is examined for possible sleep or preemption. If the process will be waiting on an event before it can continue, it will transition to the sleep state and be placed on a queue to be woken up when the event occurs. The awoken process will be marked runnable and will be a candidate for a future scheduling event. If the process is to be preempted, it is set to the runnable queue, to compete with other runnable processes for the next burst of cycles on the CPU.

It is inside the scheduler that the context switch occurs. Until the moment of the context switch, the kernel has the old context installed. Sometimes it is important to pay attention to this context, and at other times it is important to studiously ignore this context. If the kernel was entered by a syscall, it is most likely operating on behalf of the process. For instance, the process might have requested a write to a file. To carry out the write depends on the specifics of the process as captured by data in the process context. The kernel needs for the process to instruct it what is being written, where it is being written to, and how it is to be written. In this case, the kernel is said to be running in user context.

If the kernel was entered by an interrupt, the interrupt could have occurred during any process. Therefore the kernel code must not be dependent on any process context, as it cannot be assured to have any certain process context active when it the interrupt occurs and the interrupt handling code run. In this case, the kernel is said to be running in system context.

Early operating systems tended to be very passive. System context was limited to responding to interrupts. Only two types of things happened in those kernels: reacting to user requests and reacting to hardware requests. As kernels became more sophisticated they began to have plans of their own. Kernel threads were instantiated that would compete with user threads for CPU and ran exclusively in kernel context. Eventually, the scheduler was empowered to preempt kernel threads. Sometimes these types of kernels are called “fully preemptable”.