Operating Systems
Table of Contents
1. Operating Systems
Set up one process whose main purpose is to coordinate other processes, and run it on startup. This is known as the operating system, or OS. On startup, the system loads a startup program known as the BIOS (Basic Input/Output System), which is often stored on a special read-only chip. The BIOS does some quick checks, then loads the OS from memory and transfers control. The OS is then responsible for running other programs.
The operating system acts as:
- An illusionist
- any program we run doesn’t need to know that the OS or other programs exist
- any program we run doesn’t need to worry about how syscalls actually work
- A conductor
- receive commands from the user and assigns computer resources to tasks
- A referee
- keep track of what processes are running, and assign appropriate permissions
- terminate processes when they exceed what they are allowed to do
- if a program is using a lot of resources, make sure other programs also get a turn
Generally, the system provides at least two different permission levels:
- User Mode, which has limitations on what can be accessed, but is generally safer to use.
- Kernel Mode, which has more freedom, but can crash the entire system if it fails.
Usually, we want to restrict kernel mode to the OS so the user doesn’t get to do whatever it wants. We also want to restrict kernel mode to as few parts of the OS as possible, so if a part of the OS gets compromised, bad things don’t happen as easily.
2. Managing Resources
2.1. Random Access Memory
Random access memory, or RAM, is a space of memory which can be used by programs to store main memory. The OS assigns parts of RAM to processes, and when a process tries to access a memory location, the OS translates it to the corresponding spot in RAM. Different processes get different parts of RAM, so process A can’t access memory of process B (unless there is explicit memory sharing).
2.2. Sharing CPU
In order to handle multiple threads on the same CPU, we need to have a way to run a thread for a while, then context switch to another thread. A thread should not “notice” that it was paused, so we need to save its state and restore it later. The steps are:
- OS takes control from the old thread.
- OS saves the register values for the old thread.
- OS loads the register values for the new thread.
- OS transfers control to the new thread.
Context switches tend to be time consuming, so we generally run them when we have to wait for things to happen anyway. The OS is responsible for deciding when context switches happen, and which threads get access to CPU time.
2.3. System Calls
Functions like file operations and print statements can’t be directly handled by the program. These operations must transfer control back to the OS for a system call, or syscall. The OS checks if the operation is allowed, and if so, runs the operation.
3. Exceptions and Interrupts
An exception is caused by an event during the execution of a program. Exceptions are synchronous, so they must be handled immediately. Exceptions can be thought of as “unexpected events.”
A interrupt is caused by an event external to the program. Interrupts are asynchronous, so they do not need to be handled immediately. Examples include key presses or disk I/O. Interrupts can be thought of as “a request to handle.”
The trap handler is code that services exceptions and interrupts. They:
- Save the state of the current program.
- Determine what caused the exception/interrupt.
- Handle the exception/interrupt, then either continue execution or terminate the program.