CSE 380 - Operating Systems

Lecture 3 - 9/16/04 Matt Blaze

Details: Interrupts, System Calls and Processes

A more detailed look a how basic OS services are implemented on real CPUs
Traps and system calls User/supervisor mode Context switching Serving interrupts Managing processes

Efficiency issues

Whats a system call, really?

A lot like a function as far as the programmer is concerned
parameters, return value, etc function call wrapper

Main difference is that the system call executes code the OS (in supervisor mode) How to communicate parameters and return value between the program and the OS?

Calling a regular function (not a system call)

Call (typical CPU architecture):
Push calling data onto stack
parameters state (general registers, control registers, etc)

Jump to (load PC with address of) first instruction of function

Return:
pop state off stack and reload registers push return value onto stack jump to next instruction of caller (as read from stack)

Invoking a system call is similar, except:

The code for the function is in the OS
operates in supervisor mode different address space

Limited number of entry points (function addresses)

cant just jump to anywhere in the OS

System call may not return right away

programs state might change to blocked OS might decide to schedule a different program

Calling a system call

Push data onto stack
parameters to system call system call number registers, current state, etc

Issue hardware TRAP instruction sets mode bit from USER to SUPERVISOR
jumps to fixed address in OS

Calling a System Call (continuted)

OS pops and saves calling processs state from user stack
saved in process table entry

OS pops syscall number and parameters (from stack) OS calls appropriate system call function
pushes return value onto processs stack

OS calls scheduler/dispactcher to select and load next process to run

maybe the one that issued the syscall, maybe not

Returning from a system call

OS sets mode bit back to USER
and reloads state registers (PC, etc)

Now were back in the calling process

last instruction was the TRAP that issued the syscall

Process pops syscall return value from stack and gets on with its business

Interrupts
Recall that the OS can be invoked in two ways - syscalls (traps) and interrupts Interrupts are similar to TRAP instructions, except they are triggered by hardware, not by the currently running process An interrupt might occur at almost any point in a running process
the process isnt expecting it, and so isnt saving its parameters, etc returning from an interrupt means restarting from at an arbitrary point in the process

Serving an interrupt
A process is happily running along Suddenly, a hardware interrupt occurs
clock tick, I/O, illegal instruction, etc.

Hardware forces jump to fixed address in OS address space (called an Interrupt Service Routine)
pushes current state onto system stack pushes interrupt ID onto system stack

Serving an interrupt (continued)

OS interrupt handler pops interrupt ID and current process state
saves current state in process table entry looks up appropriate routine to deal with the specific interrupt ID

OS calls the appropriate routine

device driver, clock handler, etc.

Upon completion, OS calls scheduler / dispatcher to select and load user process
maybe the original one, maybe someone else

Returning from an interrupt

OS sets mode bit back to USER
and reloads state registers (PC, etc)

Now were back in a user process

last instruction was whatever it was doing

Process gets on with its business

no need to pop any return value, since process doesnt know interrupt occurred

All this should remind you of something

Examples of Interrupts
Clock pulse
every so often (say, 50 times per second) reinvoke the scheduler

Input (from keyboard, network)

add input to processs input queue change process from blocked to ready re-invoke scheduler

Illegal instruction
send signal to (or terminate) process that issued instruction

Context switching and efficiency

Going between USER and SUPERVISOR mode is expensive
have to save current process state have to restart state when done more expensive than a function call

Restarting a different process can be even more expensive

have to load a different address space likely to destroy caches and virtual memory

Some design principles

Avoid needless context switches
system calls should be limited to services that cant be performed in user mode

Blocking system calls are an efficient mechanism for a process to wait for some event (I/O, inter-process synchronization)
user-mode busy loops are a bad way to wait!

Schedulers might favor the currently running process to avoid context switch overhead
build in hysteresis but not too much - avoid starvation

Devil is in the details

These are the basic principles But details of syscall traps and interrupts vary from CPU to CPU
whats put on the stack and in what order, address space issues, etc.

Writers of this part of OS have to become experts on CPU architecture

real hackers do this stuff

Other parts of the OS are more portable

important design goal: make most of OS portable

Processes and Threads

Whats a process?
a program in execution
an address space (containing code & data) other resources (e.g. open files) some state (program counter, registers, stack pointer etc)

really two categories of things

a grouping of resources
the code & address space

a thread of execution
the current state operating on these resources

We can think about these two things separately

Threads in the process model

A lot of what the OS does is intended to keep processes from interfering with each other
every thread of execution is associated with its own grouping of resources I cant write over your processs address space

This is nice, but it means that if you want to change threads, you have to go to the OS
requires context switch to change processes this is a shame, because some applications logically consist of more than one thread but need only one grouping of resources

Multithreaded applications
Important property: one address space, no need to enforce resource separation between threads
not arbitrary code

Examples:
networked web server
serves several clients at once

web browser
load different pages simultaneously

Can we implement multiple threads in a single process?

We can do in user mode many of the functions usually handled by the OS
assumes the threads are cooperating so we dont need hardware enforcement of separation

Basic idea: a dispatcher that is called when a thread is ready to relinquish control to another thread
manages stack pointer, program counter can switch state between threads