2021-22 COMP3230A
System Calls
Process switch
Interrupt
Principles of Operating Systems 2
ILO2a - explain how OS manages processes/threads and
discuss the mechanisms and policies in efficiently sharing
of CPU resources.
Principles of Operating Systems 3
Required Reading
Chapter 6, Mechanism: Limited Direct Execution, Operating
Systems: Three Easy Pieces by Arpaci-Dusseau et. Al
http://pages.cs.wisc.edu/~remzi/OSTEP/cpu-mechanisms.pdf
Reference
Chapter 3 of Operating Systems, 3rd edition by Deitel et. al
Principles of Operating Systems 4
How to perform restricted operations?
Mechanism: System Calls
Transparent:
How to provide illusion of having many CPUs? • Process does not know
when it is running and
Virtualizing the CPU
when it is not
Mechanism: Context Switching • Programmer does not
need to worry about this
situation
How to regain control of the CPU?
Voluntary release of CPU
Mechanism: System Calls
Involuntary release of CPU
Mechanism: Interrupt
Principles of Operating Systems 5
Application
System calls allow the kernel to carefully expose
certain key services to applications API
Restricted operations in user mode User mode
Most OSs expose a few hundreds such functions Kernel mode System call interface
Mostly accessed by programs via a high-level
Application Program Interface (API) rather than directly
invoke the specific system call
Most common APIs are Win32 API for Windows, and POSIX API
for POSIX-based systems (including virtually all versions of UNIX,
Linux, and Mac OS X)
Usually, in Unix system, the API is included in the run-time
support library (e.g. C library)
Principles of Operating Systems 6
Why use APIs rather than directly invoke system calls?
Caller does not need to know how the system call is
implemented and how to invoke a specific system call in that
particular OS
Just needs to know how to use the common or standard API and
understand what OS will do / offer
Most details of OS interface hidden from programmer by API
The system call interface invokes intended system call in kernel and returns
status and results of the system call and pass back to calling program via
API
Principles of Operating Systems 7
Typically, the corresponding
library call contains a special
machine instruction (x86 – INT
or SYSCALL or SYSENTER)
Application
causing a “trap”, which results
in transfer control to the kernel
getpid( )
User mode
Kernel mode
System Call Interface
Before “trap” into kernel, either
the hardware or system call
function must sav e enough
sys_getpid()
process’s register context in
order to be able to return Implementation
correctly of getpid system
20 call in kernel
return
Principles of Operating Syst ems 8
Application
getpid( )
User mode
• Each system call is associated
Kernel mode
System Call Interface
with a number.
• This number is passed by the
function call to the kernel. sys_getpid()
Implementation
of getpid system
• Within kernel, the system-call 20 call in kernel
implementation maintains a table
indexed by these numbers. return
• Each entry consists of an address When finished, call a special
that points to the corresponding return-from-trap instruction (x86 -
system function in the kernel IRET or SYSRET or SYSEXIT) to
return into the calling user
Principles of Operating Syst ems program 9
OS @ run (kernel mode) Hardware Program (user mode)
Initialize trap table
Remember address of syscall handler
OS @ run (kernel mode) Hardware Program (user mode)
Create entry for process list; Allocate memory for
program; Load program into memory; Setup user
stack with argv; Fill kernel stack with reg/PC
return-from-trap
Restores regs (from kernel stack)
Move to user mode
Jump to main
Run main()…
Call system call
trap into OS
Save regs (to kernel stack)
Move to kernel mode
Jump to trap handler
Handle trap
Do work of system call
return-from-trap
Restore regs (from kernel stack)
Move to user mode
Jump to PC after trap
…
Return from main
trap (via exit())
Free memory of process
Remove from process list
To provide illusion that each process has its own CPU
By virtualizing, does not mean giving a virtual CPU
The program is directly running on the real CPU
Mechanism:
Time sharing the CPU: By running one process, then stopping it and running
another, and so forth
The Crux
How to transparently and temporarily stop a process and resume it?
With direct execution of application process on CPU, how can OS
regain control of the CPU?
Principles of Operating Systems 11
To stop a process, one just needs to remove it from running in CPU (to
ready state)
How can OS make sure that the process can be resumed without
affecting its execution logic?
OS needs to save the register context (the contents of CPU registers) of current
running process before stopping it
To resume, OS needs to restore the register context of the soon-to-be running
process back to CPU registers before resuming it
Question: Where to store the register context?
Context Switch
Switching of the register context of one process to another
Principles of Operating Systems 12
Action
Save the “current” process’s register context to the process’s kernel
stack
save the general purpose registers, PC, as well as the kernel stack pointer of the
currently-running process, and then restore said registers, PC, and switch to the kernel
stack for the soon-to-be-executing process.
Other Actions
Change the process’s state in PCB to appropriate status
Move the process to appropriate queue
Select a ready process (according to scheduling policy)
Load the “to be dispatched” ready process’s register context from its PCB
Update the process’s state of that going to be run process
Resume that process by turning control over to that process
Principles of Operating Systems 13
The CPU is considered as not performing any “useful”
computation for the application process
OS must minimize context-switching time
There are hardware instructions in some architectures that facilitates
the switching
Has some indirect cost (induced overheads)
The newly scheduled process may not have data and/or instructions in
the physical memory
The newly scheduled process does not have any part of its address
space in cache
Principles of Operating Systems 14
Mode switch
Switching from user mode to kernel mode
the Kernel is said to be “executing on behalf of the process”
the process’s context remains accessible (e.g., address space)
upon exiting kernel, the process may resume and return to execute in user
space
Context switch
Switching from one process to another
is an essential feature of multiprogramming or time-sharing systems
Kernel must
(1) suspends the progression of current process and stores its context
(2) retrieves the context of another process (B) and restores it to the CPU
(3) resumes execution of process B
Principles of Operating Systems 15
A Passive Approach
OS just waits for a process to make system calls or an illegal operation
Indeed, this works most of the time as processes quite frequently
invoke system calls
However, in worst case, a process gets into an infinite loop and never
makes a system call, then what can OS do!!
An Active Approach (assume non-cooperative processes)
Needs hardware support: Timer Interrupt
A timer device periodically generates an interrupt, e.g. every few
milliseconds
When the interrupt is raised, OS will be called in to handle the interrupt,
and thus can do what it wants
Principles of Operating Systems 16
Interrupt-request line triggered by hardware device
Interrupts enable OS to respond to “alerts” from hardware
May be triggered by a running process
Interrupt in this case is called an exception
Synchronous with the operation of the current process
Unexpected event from within the processor
e.g., dividing by zero or referencing protected memory
May be initiated by some event that may or may not be related to the running process
Asynchronous with the operation of the current process
Unexpected event from outside the processor
e.g., a key is pressed or the mouse is moved, timer events
Software-generated interrupt
the INT instruction
Principles of Operating Systems 17
The CPU control After receiv ing an interrupt,
processor the processor completes
responds to execution of the current
interrupts P1 instruction
and
exceptions Interrupt vector
in essentially Timer device
• OS has to sav e
the same remainder of
way. CPU has to sav e some register process state in
somewhere
contents when interrupt
occurred. It could be the • Jump to interrupt
whole set or just a few handler and
Interrupt
handler
registers. process the
interrupt
• Interrupt handlers are stored in an
array of function pointers called the
interrupt v ector
• OS sets up the v ector at boot time
The interrupt handler
• CPU reads from the system bus the determines how the
P2
interrupt v ector number prov ided by system should
an interrupt controller respond
• This number is used as an index to
locate the interrupt handler
Principles of Operating Syst ems 18
CPU control
P1
Interrupt vector
Timer device
After completion of
interrupt handling, a
decision has to be made
Interrupt
handler
by the Scheduler: restore
the interrupted process or
switch to a different one.
If the decision is to switch,
a context switch will be
made (slide # 13)
P2
Principles of Operating Syst ems 19
OS @ run (kernel mode) Hardware Program (user mode)
Initialize trap table
Remember address of syscall handler
Start interrupt timer
Start timer
I nterrupt CPU every x ms
OS @ run (kernel mode) Hardware Program (user mode)
Process A…
timer interrupt
Save regs(A) to kernel stack(A)
Move to kernel mode
Jump to trap handler
Handle trap
Call switch() routine to switch from A to B
return-from-trap (into B)
Restore regs(B) to kernel stack(B)
Move to kernel mode
Jump to B’s PC
Process B…
Three mechanisms
System call
Each call represent a service provided by the OS to user application
System mode will switch from user mode to kernel mode, and after the
service, will switch back from kernel mode to user mode
Context switch
The key action of virtualizing the CPU
The whole set of register context must be saved for the interrupted process
The register context of coming process are restored
Context switch involves certain amount of performance overhead
Interrupt processing
A mechanism for hardware devices to alert OS for handling high-priority
events
This gives a chance to OS to regain control of CPUs
Principles of Operating Systems 21