OS 공부 2주차

suntlee·2020년 12월 20일

Mechanism: Limited Direct Execution

Virtualization is achieved by time sharing the CPU.

2 challenges

  1. Performance: implement without excessive overhead
  2. Control: run processes while retaining control over the CPU

To deal with these challenges, both hardware and operating-system support will be required.

Direct Execution


  1. How can the OS make sure the program doesn't do anything that we don't want it to do
  2. How does the OS stop if from running and switch to another process -> time sharing

Problem 1: Restricted Operations

We have two processor modes. One is user mode and the other is kernel mode.

  1. User mode: code that runs in user mode is restricted in what it can do.
  2. Kernel mode: In which the OS runs. Code that runs in this mode can do what it likes, including privileged operations such as issuing I/O requests and executing all types of restricted instructions.

What should a user process do when it wishes to perform some kind of privileged operation?

To enable this, virtually all modern hardware provides the ability for user programs to perform a system call. System calls allow the kernel to carefully expose certain key pieces of functionality to user programs, such as accessing the file system, creating and destroying processes, communicating with other processes, and allocating more memory.


The hardware assists the OS by providing different modes of execution.
In user mode, applications do not have full access to hardware resources.
In kernel mode, the OS has access to the full resources of the machine.
Special instructions to trap into the kernel and return-from-trap back to
user-mode programs are also provided, as well as instructions that allow
the OS to tell the hardware where the trap table resides in memory.

trap - return-from-trap

H/W: push/pop PC, flags, registers onto/from a per-process kernel stack;.

How does the trap know which code to run inside the OS?

->Use a trap table set up at boot time.

a system-call number is usually assigned to each system call. The user code is thus responsible for placing the desired system-call number in a register or at a specified location on the stack; the OS, when handling the system call inside the trap handler,
examines this number, ensures it is valid, and, if it is, executes the corresponding

Problem 2: Switching between processes

How can the OS regain control of the CPU so that it can switch between processes?

How can the OS gain control of the CPU even if processes are not being cooperative? What can the OS do to ensure a rogue process does not take over the machine?

The answer is a timer interrupt.

Now that the OS has regained control, whether cooperatively via a system
call, or more forcefully via a timer interrupt, a decision has to be
made: whether to continue running the currently-running process, or
switch to a different one. This decision is made by a part of the operating
system known as the scheduler;

Context switch: all the OS has to do is save a few register values for the currently-executing process and restore a few for the soon-to-be-executing process.

  1. save context
  2. switch stacks
  3. restore context

Note that there are two types of register saves/restores that happen
during this protocol. The first is when the timer interrupt occurs; in this
case, the user registers of the running process are implicitly saved by the
hardware, using the kernel stack of that process. The second is when the
OS decides to switch from A to B; in this case, the kernel registers are explicitly
saved by the software (i.e., the OS), but this time into memory in
the process structure of the process. The latter action moves the system
from running as if it just trapped into the kernel from A to as if it just
trapped into the kernel from B.


관심 있을 만한 포스트

0개의 댓글