Process Concept
Course "Operating Systems"
Chapter 3
Prof. Dr. Reinhard von Hanxleden
Real Time / Embedded Systems Group
Dept. of Computer Science
Kiel University
rvh@informatik.uni-kiel.de
The 5-Minute Review Session
Informatik ∙ CAU Kiel
1. What is a TLB?
2. What are the trade-offs regarding page size?
3. What page-replacement algorithms do you know?
4. What is the Belady anomaly?
5. What is thrashing? How do we avoid it?
© N. Luttenberger
2
Overview
Informatik ∙ CAU Kiel
1. Introduction: What is a Process?
2. Process Creation and Termination
3. Processes in the OS
4. Interrupt and Trap Handling
5. Sample Code from the Minix OS
© N. Luttenberger
3
1.
Introduction: What is a Process?
Process Concept
Informatik ∙ CAU Kiel
• Different kinds of operating systems
– Batch system
o
executes jobs
– Time-shared system
o
executes user programs or tasks
– Interactive system
o
© N. Luttenberger
executes processes
5
Process Concept
Informatik ∙ CAU Kiel
• A process is an
instance of a program
– Not the same as "program".
– One of the most profound ideas in computer science.
© N. Luttenberger
6
Process Concept
Informatik ∙ CAU Kiel
• Process provides each program with two key abstractions
– Private address space
o
Each process seems to have exclusive use of main memory.
– Logical control flow
o
Each process seems to have exclusive use of a processor.
• How are these illusions maintained?
– Address spaces managed by the OS
– Process executions are interleaved
© N. Luttenberger
7
Process Concept
Informatik ∙ CAU Kiel
• Each process
has its
private
address space.
0xffffffff
kernel virtual memory
(code, data, heap, stack)
0xc0000000
0x40000000
user stack
(created at runtime)
read/write segment
(.data, .bss)
© N. Luttenberger
0
%esp (stack pointer)
memory mapped region for
shared libraries
run-time heap
(managed by malloc)
0x08048000
memory
invisible to
user code
read-only segment
(.init, .text, .rodata)
brk
loaded from the
executable file
unused
8
Process Concept
Informatik ∙ CAU Kiel
• Logical control flow
– Single thread of execution on a monoprocessor
PC
© N. Luttenberger
hardware provides a single
Program Counter (PC)
register
9
Process Concept
Informatik ∙ CAU Kiel
• Four processes running on a monoprocessor
– Conceptual model: 4 independent processes
Single PC
(CPU’s point of view)
Multiple PCs
(process point of view)
A
B
C
B
D
© N. Luttenberger
A
B
C
D
D
C
B
A
Time
10
Process Concept
Informatik ∙ CAU Kiel
• Processes are managed by a shared chunk of OS code
called the kernel
– Important: the kernel is not a separate process,
but rather runs as part of some user process
– Control flow passes from one process to another
via a process switch or context switch.
© N. Luttenberger
11
Process Concept
Informatik ∙ CAU Kiel
• Context/process switch
Process A
code
Process B
code
user code
Time
kernel code
context/process
switch
user code
kernel code
context/process
switch
user code
© N. Luttenberger
12
Process Concept
Informatik ∙ CAU Kiel
• Two processes run concurrently (are concurrent),
if their flows overlap in time.
– Control flows for concurrent processes are disjoint in time.
– However, we can think of concurrent processes are running in parallel
with each other.
© N. Luttenberger
13
Process Concept
Informatik ∙ CAU Kiel
• Process state
– program counter (pointing to some location in the code)
– CPU registers
– stack pointer
– resources owned
– state as seen from the OS
– other
© N. Luttenberger
14
Process Concept
Informatik ∙ CAU Kiel
• Process control block
(simplified)
– Created and managed
by the operating system
– Allows the OS to support
multiple processes
© N. Luttenberger
15
2.
Process Creation and Termination
Process Creation
Informatik ∙ CAU Kiel
• Processes can be created in two ways
– System initialization:
one or more processes created when the OS starts up
– Execution of a process creation system call:
something explicitly asks for a new process
• System calls can come from
– User request to create a new process (user shell)
– Already running processes
o
User programs
o
System daemons
© N. Luttenberger
17
Process Creation
Informatik ∙ CAU Kiel
• Reasons for process creation
new batch job
OS is provided with batch job control stream,
containing e.g. a nightly backup job
interactive logon
A new user at a terminal logs on to the
system.
created by OS
OS creates process to provide some service,
e.g. a print process
spawned by existing process
A user process wants to exploit parallelism,
e.g. make use of a multi-core system.
© N. Luttenberger
18
Process Creation
Informatik ∙ CAU Kiel
• UNIX
–
fork system call creates new process
– Child duplicate of parent
–
exec system call used after a fork
to replace the process’ memory space
with a new program text and data
© N. Luttenberger
19
Process Creation
Informatik ∙ CAU Kiel
• UNIX fork
– Parent process creates child process
that is identical to the calling process (parent process)
– Child process, in turn, may create
other processes, forming a tree of processes
– Execution
o
parent and children execute concurrently
o
parent waits until children terminate
– Parent and children share all/subset of/no resources
© N. Luttenberger
20
Process Creation
Informatik ∙ CAU Kiel
• UNIX: int fork(void)
– returns 0 to the child process
– returns child’s pid to the parent process
if (fork() == 0) {
printf("hello from child\n");
} else {
printf("hello from parent\n");
}
© N. Luttenberger
Fork is interesting
(and often confusing)
because it is called
once but returns twice
21
Process Creation
Informatik ∙ CAU Kiel
• Running new programs:
int execl(char *path, char *arg0, char *arg1, …, 0)
– loads and runs executable at path with args arg0, arg1, …
o
path is the complete path of an executable
o
arg0 becomes the name of the process:
typically arg0 is either identical to path, or else
it contains only the executable filename from path
o
"real" arguments to the executable start with arg1, etc.
o
list of args is terminated by a (char *)0 argument
– returns -1 if error, otherwise doesn’t return!
© N. Luttenberger
22
Process Creation
Informatik ∙ CAU Kiel
• Running new programs:
int execl(char *path, char *arg0, char *arg1, …, 0)
main() {
if (fork() == 0) {
execl("/usr/bin/cp", "cp", "foo", "bar", 0);
}
wait(NULL);
printf("copy completed\n");
exit();
}
© N. Luttenberger
23
Process Creation
Informatik ∙ CAU Kiel
•
Fork Example #1
– Parent and child both run same code
o
Distinguish parent from child by return value from fork
void fork1()
{
int x = 1;
pid_t pid = fork();
if (pid == 0) {
printf("Child has x = %d\n", ++x);
} else {
printf("Parent has x = %d\n", --x);
}
printf("Bye from process %d with x = %d\n", getpid(), x);
}
© N. Luttenberger
24
Process Creation
Informatik ∙ CAU Kiel
•
Fork Example #1 (cont'd.)
– Start with same state, but each has private copy
o
Including shared output file descriptor
o
Relative ordering of their print statements undefined
void fork1()
{
int x = 1;
pid_t pid = fork();
if (pid == 0) {
printf("Child has x = %d\n", ++x);
} else {
printf("Parent has x = %d\n", --x);
}
printf("Bye from process %d with x = %d\n", getpid(), x);
}
© N. Luttenberger
25
Process Creation
Informatik ∙ CAU Kiel
•
Fork Example #2
– Both parent and child can continue forking
void fork2()
{
printf("L0\n");
fork();
printf("L1\n");
fork();
printf("Bye\n");
}
© N. Luttenberger
Bye
L1
Bye
Bye
L0
L1
Bye
26
Process Creation
Informatik ∙ CAU Kiel
•
Fork Example #3
– Both parent and child can continue forking
void fork3()
{
printf("L0\n");
fork();
printf("L1\n");
fork();
printf("L2\n");
fork();
printf("Bye\n");
}
© N. Luttenberger
Bye
L2
Bye
Bye
L1
L2
Bye
Bye
L2
Bye
Bye
L0
L1
L2
Bye
27
Process Creation
Informatik ∙ CAU Kiel
•
Fork Example #4
– Both parent and child can continue forking
void fork4()
{
printf("L0\n");
if (fork() != 0) {
printf("L1\n");
if (fork() != 0) {
printf("L2\n");
fork();
}
}
printf("Bye\n");
}
© N. Luttenberger
Bye
Bye
Bye
L0
L1
L2
Bye
28
Process Creation
Informatik ∙ CAU Kiel
•
Fork Example #5
– Both parent and child can continue forking
void fork5()
{
printf("L0\n");
if (fork() == 0) {
printf("L1\n");
if (fork() == 0) {
printf("L2\n");
fork();
}
}
printf("Bye\n");
}
© N. Luttenberger
Bye
L2
L1
L0
Bye
Bye
Bye
29
Process Creation
Informatik ∙ CAU Kiel
• WIN 32
© N. Luttenberger
30
Process Creation
Informatik ∙ CAU Kiel
• Java
© N. Luttenberger
31
Process Termination
Informatik ∙ CAU Kiel
• Conditions that terminate processes can be
– Voluntary
o
Normal exit
o
Error exit
– Involuntary
o
Fatal error (only sort of involuntary)
o
Killed by another process
© N. Luttenberger
32
Process Termination
Informatik ∙ CAU Kiel
• Reasons for process termination
Normal completion
Process executes OS service call to indicate process
completion.
Time limit exceeded
Different time limits possible: total elapsed time,
total run time, time between two user inputs
Memory unavailable
Process requires more memory than can be
provided.
Bounds violation
Process tries to access a memory location that is
not allowed to be accessed.
Protection error
Process tries to use a resource in an improper
fashion.
Arithmetic error
Process tries a prohibited computation.
Time overrun
Process has waited longer than a specified
maximum for a certain event.
© N. Luttenberger
33
Process Termination
Informatik ∙ CAU Kiel
• Reasons for process termination (cont'd.)
I/O failure
An error during I/O occurred
Invalid instruction
Process attempts to execute an invalid instruction.
Privileged instruction
Process attempts to execute a privileged
instruction, e.g. an instruction reserved for the OS.
Data misuse
A piece of data of the wrong type or not initialized.
Operator or OS intervention
Process is cancelled by operator or OS.
Parent termination
When a parent process terminates, the OS may
automatically terminate all offspring of that
parent.
Parent request
A parent process typically has the authority to
terminate any of ist offspring.
© N. Luttenberger
34
Process Termination
Informatik ∙ CAU Kiel
• UNIX: void exit(int status)
– exits a process
o
Normally return with status 0
– atexit() registers functions to be executed upon exit
void cleanup(void) {
printf("cleaning up\n");
}
void fork6() {
atexit(cleanup);
fork();
exit(0);
}
© N. Luttenberger
35
Zombies
Informatik ∙ CAU Kiel
• Zombies
– When process terminates, still consumes system resources
o
Various tables maintained by OS
– Called a “zombie”
o
Living corpse, half alive and half dead
• Reaping
– Performed by parent on terminated child
– Parent is given exit status information
– Kernel discards process
© N. Luttenberger
36
Zombies
Informatik ∙ CAU Kiel
• What if parent doesn’t reap?
– If any parent terminates without reaping a child, then child will be
reaped by init process
– Only need explicit reaping for long-running processes
o
© N. Luttenberger
E.g., shells and servers
37
Zombie Example
Informatik ∙ CAU Kiel
– ps shows child process as “defunct”
– Killing parent allows child to be reaped
linux> ./forks 7 &
[1] 6639
void fork7()
Running Parent, PID = 6639
{
Terminating Child, PID = 6640
if (fork() == 0) {
linux> ps
/* Child */
printf("Terminating Child, PID =PID
%d\n",
TTY
TIME CMD
getpid());
6585 ttyp9
00:00:00 tcsh
exit(0);
6639 ttyp9
00:00:03 forks
} else {
6640 ttyp9
00:00:00 forks <defunct>
printf("Running Parent, PID = %d\n",
6641 ttyp9
00:00:00 ps
getpid());
linux> kill 6639
while (1)
; /* Infinite loop */
[1]
Terminated
}
linux> ps
}
PID TTY
TIME CMD
6585 ttyp9
00:00:00 tcsh
6642 ttyp9
00:00:00 ps
© N. Luttenberger
38
Zombies
Informatik ∙ CAU Kiel
• Nonterminating Child
– Child process still active even though parent has terminated
– Must kill explicitly, or else will keep running indefinitely
linux> ./forks 8
Terminating Parent, PID = 6675
Running Child, PID = 6676
linux> ps
PID TTY
TIME CMD
6585 ttyp9
00:00:00 tcsh
6676 ttyp9
00:00:06 forks
6677 ttyp9
00:00:00 ps
linux> kill 6676
linux> ps
PID TTY
TIME CMD
6585 ttyp9
00:00:00 tcsh
6678© N.
ttyp9
Luttenberger 00:00:00 ps
void fork8()
{
if (fork() == 0) {
/* Child */
printf("Running Child,
PID = %d\n", getpid());
while (1)
; /* Infinite loop */
} else {
printf("Terminating Parent,
PID = %d\n", getpid());
exit(0);
}
}
39
Synchronizing with Children
Informatik ∙ CAU Kiel
• Synchronizing with children:
int wait(int *child_status)
– suspends current process until one of its children terminates
– return value is the pid of the child process that terminated
– if child_status != NULL, then the object it points to will be set
to a status indicating why the child process terminated
© N. Luttenberger
40
Synchronizing with Children
Informatik ∙ CAU Kiel
•
int wait(int *child_status)
void fork9() {
int child_status;
if (fork() == 0) {
printf("HC: hello from child\n");
}
else {
printf("HP: hello from parent\n");
wait(&child_status);
printf("CT: child has terminated\n");
}
printf("Bye\n");
exit();
HC Bye
HP
CT Bye
}
© N. Luttenberger
41
3.
Processes in the OS
Processes in the OS
Informatik ∙ CAU Kiel
• Two "layers" for processes
Processes
Interrupt Service Routines
– Lower layer: interrupt handling
– Upper layer: process management
○
Processes tracked in the process table
○
Each process has a process control block (a process table entry)
© N. Luttenberger
47
Process Behaviour
Informatik ∙ CAU Kiel
• Most application programs can’t execute continuously
for a longer period of time
– Waiting for user input
– Waiting for a message
– Waiting for a free buffer to send a message
– Waiting for a block from disk
– Waiting for memory allocation
© N. Luttenberger
48
Process Behaviour
Informatik ∙ CAU Kiel
• Some can
– Number crunching, cryptography, simulations, …
– Complex operations on large images (e.g. Photoshop)
– Realtime games, chess, …
© N. Luttenberger
49
Process Behaviour
Informatik ∙ CAU Kiel
• Bursts of CPU usage alternate with periods of I/O wait
– Some processes are CPU-bound: they don’t make many I/O requests
– Other processes are I/O-bound and make many OS requests
Total CPU usage
CPU bound
CPU bursts
I/O waits
I/O bound
Total CPU usage
Time
© N. Luttenberger
50
Process Behaviour
Informatik ∙ CAU Kiel
• Different phases of program behavior are called bursts
– CPU burst
o
Process uses CPU
o
Burst length depends on type of application
– I/O burst
o
Process is waiting for some I/O operation to complete
o
No CPU time consumption
o
Most I/O bursts last at least for several milliseconds or longer
• Can OS exploit this typical program behavior?
© N. Luttenberger
51
Process Traces
Informatik ∙ CAU Kiel
• Time multiplex on a single processor
– Process switch initiated by periodical timer interrupt
– Typical time slice value: 10 – 20 ms
– Is supported by most Operating Systems
P1
P2
P3
Pn-1
Pn
© N. Luttenberger
52
Process Traces
Informatik ∙ CAU Kiel
• Trace of a process
– Sequence of instructions
that execute for a process
– Dispatcher switches
the processor from
one process to another
© N. Luttenberger
53
Process Traces
Informatik ∙ CAU Kiel
• Three process traces in isolation
© N. Luttenberger
54
Process Traces
Informatik ∙ CAU Kiel
• Combined
trace of three
processes
Timer
Timer
Timer
I/O request
Dispatcher
© N. Luttenberger
Timer
55
Process Traces
Informatik ∙ CAU Kiel
• Gantt chart
© N. Luttenberger
56
Process States
Informatik ∙ CAU Kiel
• Goal
Step-by-step development of a state model
describing the states a process can be in
and the related state transitions
© N. Luttenberger
57
Process States
Informatik ∙ CAU Kiel
• Initial Model:
Process may be in one of two states
– Running
– Not-running
© N. Luttenberger
58
Process States
Informatik ∙ CAU Kiel
• Queuing model
© N. Luttenberger
59
Process States
Informatik ∙ CAU Kiel
• Process states—third state
1.
Running
(actually using the CPU at that instant).
2.
Ready
(runnable; temporarily stopped to let another process run).
3.
Blocked
(unable to run until some external event happens).
© N. Luttenberger
60
Process States
Informatik ∙ CAU Kiel
• Five-state process model
Timer
© N. Luttenberger
61
Process States
Informatik ∙ CAU Kiel
• State transitions
Null → New
Process is created (see previous table).
New → Ready
OS accepts process and allocates memory to process.
Ready → Running
OS assigns processor to process.
Running → Exit
Process is terminated (see previous table).
Running → Ready
Preemption: processor is reclaimed by OS before process
has terminated. Several reasons, e.g. time slice expired.
Running → Blocked
Process engages in activity with unknown duration, i.e.
waiting for some event in the future. Sample events:
"I/O operation finished" or "message received from other
process". Engagement via OS call.
Blocked → Ready
Waited-for event has occurred.
Ready → Exit
Typically by parent request; not shown in state diagram.
Blocked → Exit
See above.
© N. Luttenberger
62
Process States
Informatik ∙ CAU Kiel
• Queuing model with single blocked queue
Timer
© N. Luttenberger
63
Process States
Informatik ∙ CAU Kiel
• Queuing model with multiple blocked queues
Timer
© N. Luttenberger
64
Process States
Informatik ∙ CAU Kiel
• Introduction of a new process state: suspended
– Processor is faster than I/O
→ so all processes could be waiting for I/O
– Swap these processes to disk to free up memory
– Blocked state becomes suspended state when swapped to disk
– Two new state transitions:
o
Blocked → Suspended: suspend
o
Suspended → Ready:
© N. Luttenberger
activate
65
Process States
Informatik ∙ CAU Kiel
• State diagram with one Suspend state
Timer
© N. Luttenberger
66
Process States
Informatik ∙ CAU Kiel
• Reasons for process suspension
– OS wants to bring in a ready process.
– Time slice for process exhausted.
– Interactive user request for suspension.
– Parent process request.
– OS suspends process for other reason.
© N. Luttenberger
67
Process States
Informatik ∙ CAU Kiel
• Introduction of the
blocked/suspend and ready/suspend states
– After swapping out: Which process to swap in?
o
Process to swap in is blocked!
o
Useless swap-in operations?
– Introduce two new states:
o
blocked/suspend
o
ready/suspend
– For swap-in, select a process that is in ready/suspend state.
© N. Luttenberger
68
Process States
Informatik ∙ CAU Kiel
• State diagram with two suspend states
Timer
© N. Luttenberger
69
Process States
Informatik ∙ CAU Kiel
• State transitions
Blocked →
Blocked/Suspend
Blocked process is swapped out to make room for a
process in
ready or ready/suspend state
Blocked/Suspend →
Ready/Suspend
A blocked/suspend process is moved to the
ready/suspend state, when the event for which the
process has been waiting occurs.
Ready/Suspend → Ready
If no ready processes are present in main memory,
the OS may decide to swap in a suspended process;
alternatively, a suspended process with priority
higher than all ready processes may be swapped in.
Ready → Ready/Suspend
OS wants to free memory for other process.
© N. Luttenberger
70
UNIX SVR4 Process Management
Informatik ∙ CAU Kiel
• Process states
© N. Luttenberger
71
UNIX SVR4 Process Management
Informatik ∙ CAU Kiel
• State transition diagram
© N. Luttenberger
72
OS Control Structures
Informatik ∙ CAU Kiel
• Information about the current status
of each process and each resource
– memory tables
– I/O tables
– files tables
– process tables
© N. Luttenberger
73
OS Control Structures
Informatik ∙ CAU Kiel
• Overview
© N. Luttenberger
74
OS Control Structures
Informatik ∙ CAU Kiel
• Memory Tables
– Allocation of main memory to processes
– Allocation of secondary memory to processes
– Protection attributes for access to shared memory regions
– Information needed to manage virtual memory
© N. Luttenberger
75
OS Control Structures
Informatik ∙ CAU Kiel
• I/O Tables
– I/O device is available or assigned
– Status of I/O operation
– Location in main memory being used as the source or destination of
the I/O transfer
© N. Luttenberger
76
OS Control Structures
Informatik ∙ CAU Kiel
• File Tables
– Existence of files
– Location on secondary memory
– Current Status
– Attributes
– Sometimes this information is maintained by a file management
system
© N. Luttenberger
77
What’s in a process table entry?
Informatik ∙ CAU Kiel
May be
stored
on stack
Process management
File management
Registers
Program counter
CPU status word
Stack pointer
Process state
Priority / scheduling parameters
Process ID
Parent process ID
Signals
Process start time
Total CPU usage
Root directory
Working (current) directory
File descriptors
User ID
Group ID
© N. Luttenberger
Memory management
Pointers to text, data, stack
or
Pointer to page table
78
OS Control Structures
Informatik ∙ CAU Kiel
• Elements of a Process Table Entry
Process Identification
Identifiers
Identifier of this process
Identifier of the parent process
User identifier
Process State Information
User-Visible Registers
A user-visible register is one that may be referenced by means of
the machine language that the processor executes while in user
mode. Typically. there are from 8 to 32 of these registers, although
some RISC implementations have over 100.
© N. Luttenberger
79
OS Control Structures
Informatik ∙ CAU Kiel
• Elements of a Process Table Entry (cont'd.)
Process State Information (cont'd.)
Control and Status Registers
Program counter
Contains the address of the next instruction to be
fetched
Condition codes
Result of the most recent arithmetic or logical
operation (e.g., sign, zero, carry, equal, overflow)
Status information
Includes interrupt enabled, disabled flags,
execution mode
Stack Pointers
Each process has one or more last-in-first-out (LIFO) system stacks
associated with it. A stack is used to store parameters and calling
addresses for procedure and system calls. The stack pointer points
to the top of the stack.
© N. Luttenberger
80
OS Control Structures
Informatik ∙ CAU Kiel
• Elements of a Process Table Entry (cont'd.)
Process Control Information
Scheduling and State Information
© N. Luttenberger
Process state
Defines the readiness of the process to be scheduled
for execution (e.g., running, ready, suspend, blocked).
Priority
Scheduling priority of the process. In some systems.
several values are required (e.g.. default, current,
highest-allowable).
Scheduling
information
Depends on the scheduling algorithm used, e.g.
the amount of time that the process has been
waiting and the amount of time that the process
executed the last time it was running.
Event
Identity of the event the process is awaiting before it
can be resumed.
81
OS Control Structures
Informatik ∙ CAU Kiel
• Elements of a Process Table Entry (cont'd.)
Process Control Information (cont'd.)
Data Structuring
A process may be linked to other process in a queue, ring, or some other
structure. For example, all processes in a waiting state for a particular
priority level may be linked in a queue. A process may exhibit a parentchild (creator-created) relationship with another process. The process
control block may contain pointers to other processes to support these
structures.
Interprocess Communication
Various flags, signals, and messages may be associated with
communication between two independent processes. Some or all of this
information may be maintained in the process control block.
© N. Luttenberger
82
OS Control Structures
Informatik ∙ CAU Kiel
• Elements of a Process Table Entry (cont'd.)
Process Control Information (cont'd.)
Process Privileges
Processes are granted privileges in terms of the memory that may be
accessed and the types of instructions that may be executed. In addition,
privileges may apply to the use of system utilities and services.
Memory Management
This section may include pointers to segment and/or page tables that
describe the virtual memory assigned to this process.
Resource Ownership and Utilization
Resources controlled by the process may be indicated, such as opened
files. A history of utilization of the processor or other resources may also
be included; this information may be needed by the scheduler.
© N. Luttenberger
83
OS Control Structures
Informatik ∙ CAU Kiel
• Linking of Process Table Entries
running
ready
r&s
b&s
PCB
Process Control Block (PCB)
…
© N. Luttenberger
PCB
PCB
PCB
PCB
PCB
PCB
PCB
PCB
PCB
PCB
84
Process Control
Informatik ∙ CAU Kiel
• Modes of Execution
– User mode
o
Less-privileged mode
o
User programs typically execute in this mode
– System mode, control mode, or kernel mode
o
More-privileged mode
o
Kernel of the operating system
© N. Luttenberger
85
4.
Interrupt and Trap Handling
Processes in the OS
Informatik ∙ CAU Kiel
• Two "layers" for processes
Processes
Interrupt Service Routines
– Lower layer: interrupt handling
– Upper layer: process management
○
Processes tracked in the process table
○
Each process has a process control block (a process table entry)
© N. Luttenberger
87
Sources for Interrupts
Informatik ∙ CAU Kiel
Keyboard
Processor
Interrupt
controller
Mouse
Keyboard
controller
Modem
Serial port
controller
Printer
Parallel port
controller
Local/IO Bus
Memory
IDE disk
controller
SCSI
controller
Video
adapter
Network
adapter
Display
Network
SCSI bus
disk
disk
© N. Luttenberger
CDROM
88
What happens on a trap/interrupt?
Informatik ∙ CAU Kiel
1. Hardware saves program counter (on stack or in a special register)
2. Hardware loads new PC, identifies interrupt
3. Assembly language routine saves registers
4. Assembly language routine sets up stack
5. Assembly language calls C to run service routine
6. Service routine calls scheduler
7. Scheduler selects a process to run next (might be the one interrupted …)
8. Assembly language routine loads PC & registers for the selected process
© N. Luttenberger
89
Exceptions
Informatik ∙ CAU Kiel
• An exception is a transfer of control to the OS in response to
some event (i.e., change in processor state)
User Process
event
current
next
OS
exception
exception processing
by exception handler
exception
return (optional)
© N. Luttenberger
90
Interrupt Vectors
Informatik ∙ CAU Kiel
– Each type of event has a unique exception number k
– Index into jump table (a.k.a., interrupt vector)
– Jump table entry k points to a function (exception handler).
– Handler k is called each time exception k occurs.
code for
exception handler 0
Exception
numbers
interrupt
vector
0
1
2
n-1
© N. Luttenberger
...
code for
exception handler 1
code for
exception handler 2
...
code for
exception handler n-1
91
Asynchronous Exceptions (Interrupts)
Informatik ∙ CAU Kiel
• Caused by events external to the processor
– Indicated by setting the processor’s interrupt pin
– Handler returns to “next” instruction.
• Examples
–
I/O interrupts
○
hitting ctl-c at the keyboard
○
arrival of a packet from a
network
○
© N. Luttenberger
–
Hard reset interrupt
○
–
hitting the reset button
Soft reset interrupt
○
hitting ctl-alt-delete on a PC
arrival of a data sector from a
disk
92
Synchronous Exceptions
Informatik ∙ CAU Kiel
• Caused by executing an instruction
– Traps
○
Intentional
○
Examples: system calls,
breakpoint traps,
special instructions
○
Returns control to
"next" instruction
– Faults
○
Unintentional, but possibly
recoverable, e.g.
page faults (recoverable),
protection faults (unrecoverable).
○
Either re-executes faulting
("current") instruction or aborts.
– Aborts
○
Unintentional and unrecoverable,
e.g. parity error, machine check
○
Aborts current program
© N. Luttenberger
93
Trap Example
Informatik ∙ CAU Kiel
• Opening a File
– User calls open(filename, options)
OS
User Process
0804d070 <__libc_open>:
. . .
804d082:
cd 80
804d084:
5b
. . .
○
int
pop
$0x80
%ebx
exception
int
pop
return
Open
file
Function open executes system call instruction int
– OS must find or create file, get it ready for reading or writing
– Returns integer file descriptor
© N. Luttenberger
94
Fault Example #1
Informatik ∙ CAU Kiel
• Memory Reference
int a[1000];
main ()
{
a[500] = 13;
}
– User writes to memory location
– That page is currently on disk
80483b7:
c7 05 10 9d 04 08 0d
movl
$0xd,0x8049d10
– Page handler must load page into physical memory
– Returns to faulting instruction
– Successful on second try
User Process
event
© N. Luttenberger
movl
OS
page fault
return
Create page and load
into memory
95
Fault Example #2
Informatik ∙ CAU Kiel
• Memory Reference
int a[1000];
main ()
{
a[5000] = 13;
}
– User writes to memory location
– Address is not valid
80483b7:
c7 05 60 e3 04 08 0d
movl
$0xd,0x804e360
– Page handler detects invalid address
– Sends SIGSEG signal to user process
– User process exits with “segmentation fault”
User Process
event
movl
OS
page fault
Detect invalid address
© N. Luttenberger
Signal process
96
5.
Sample Code From the Minix OS
The Internal Structure of MINIX
Informatik ∙ CAU Kiel
• MINIX 3 is structured in four layers.
Only processes in the bottom layer may use
privileged (kernel mode) instructions.
© N. Luttenberger
98
Restart
Informatik ∙ CAU Kiel
• Restart is the common point reached after system startup,
interrupts, or system calls. The most deserving process runs
next.
(Not shown
in this diagram
are interrupts
that occur while
the kernel itself
is running.)
© N. Luttenberger
99
Scheduling in MINIX
Informatik ∙ CAU Kiel
• The scheduler maintains sixteen queues, one per priority
level. Shown here is the initial queuing process as MINIX 3
starts up.
© N. Luttenberger
100
Scheduling in MINIX (2)
Informatik ∙ CAU Kiel
• Determining the right position in the selected queue
– put at tail of queue when quantum has been used up:
round robin
– put at head of queue when de-blocked:
ready to use remaining quantum
© N. Luttenberger
101
Implementation of Processes
Informatik ∙ CAU Kiel
• Some of the fields of the MINIX 3 process table.
© N. Luttenberger
102
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
servers/pm/mproc.h
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
17600
17601
17602
17603
17604
17605
17606
17607
17608
17609
17610
17611
17612
17613
17614
17615
17616
17617
17618
17619
17620
17621
17622
17623
17624
17625
17626
17627
17628
17629
17630
/* This table has one slot per process. It contains all the process management
* information for each process. Among other things, it defines the text, data
* and stack segments, uids and gids, and various flags. The kernel and file
* systems have tables that are also indexed by process, with the contents
* of corresponding slots referring to the same process in all three.
*/
#include <timers.h>
EXTERN struct mproc {
struct mem_map mp_seg[NR_LOCAL_SEGS]; /* points to text, data, stack */
char mp_exitstatus;
/* storage for status when process exits */
char mp_sigstatus;
/* storage for signal # for killed procs */
pid_t mp_pid;
/* process id */
pid_t mp_procgrp;
/* pid of process group (used for signals) */
pid_t mp_wpid;
/* pid this process is waiting for */
int mp_parent;
/* index of parent process */
/* Child user and system times. Accounting done on child exit. */
clock_t mp_child_utime;
/* cumulative user time of children */
clock_t mp_child_stime;
/* cumulative sys time of children */
/* Real and effective uids and gids. */
uid_t mp_realuid;
/* process' real uid */
uid_t mp_effuid;
/* process' effective uid */
gid_t mp_realgid;
/* process' real gid */
gid_t mp_effgid;
/* process' effective gid */
/* File identification for sharing. */
ino_t mp_ino;
/* inode number of file */
dev_t mp_dev;
/* device number of file system */
time_t mp_ctime;
/* inode changed time */
18427
18428
18429
18430
18431
18432
18433
18434
18435
18436
18437
18438
18439
18440
18441
18442
18443
18444
18445
18446
18447
18448
18449
18450
18451
18452
18453
18454
18455
18456
18457
18458
18459
18460
18461
18462
/*===========================================================================*
*
do_fork
*
*===========================================================================*/
PUBLIC int do_fork()
{
/* The process pointed to by 'mp' has forked. Create a child process. */
register struct mproc *rmp;
/* pointer to parent */
register struct mproc *rmc;
/* pointer to child */
int child_nr, s;
phys_clicks prog_clicks, child_base;
phys_bytes prog_bytes, parent_abs, child_abs; /* Intel only */
pid_t new_pid;
/* If tables might fill up during FORK, don't even start since recovery half
* way through is such a nuisance.
*/
rmp = mp;
if ((procs_in_use == NR_PROCS) ||
(procs_in_use >= NR_PROCS-LAST_FEW && rmp->mp_effuid != 0))
{
printf("PM: warning, process table is full!\n");
return(EAGAIN);
}
/* Determine how much memory to allocate. Only the data and stack need to
* be copied, because the text segment is either shared or of zero length.
*/
prog_clicks = (phys_clicks) rmp->mp_seg[S].mem_len;
prog_clicks += (rmp->mp_seg[S].mem_vir - rmp->mp_seg[D].mem_vir);
prog_bytes = (phys_bytes) prog_clicks << CLICK_SHIFT;
if ( (child_base = alloc_mem(prog_clicks)) == NO_MEM) return(ENOMEM);
/* Create a copy of the parent's core image for the child. */
child_abs = (phys_bytes) child_base << CLICK_SHIFT;
parent_abs = (phys_bytes) rmp->mp_seg[D].mem_phys << CLICK_SHIFT;
s = sys_abscopy(parent_abs, child_abs, prog_bytes);
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/proc.h
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
05500
05501
05502
05503
05504
05505
05506
05507
05508
05509
05510
05511
05512
05513
05514
05515
05516
05517
05518
05519
05520
05521
05522
05523
05524
05525
05526
05527
05528
05529
05530
05531
#ifndef PROC_H
#define PROC_H
/* Here is the declaration of the process table. It contains all process
* data, including registers, flags, scheduling priority, memory map,
* accounting, message passing (IPC) information, and so on.
*
* Many assembly code routines reference fields in it. The offsets to these
* fields are defined in the assembler include file sconst.h. When changing
* struct proc, be sure to change sconst.h to match.
*/
#include <minix/com.h>
#include "protect.h"
#include "const.h"
#include "priv.h"
struct proc {
struct stackframe_s p_reg;
/* process' registers saved in stack frame */
reg_t p_ldt_sel;
/* selector in gdt with ldt base and limit */
struct segdesc_s p_ldt[2+NR_REMOTE_SEGS]; /* CS, DS and remote segments */
proc_nr_t p_nr;
struct priv *p_priv;
char p_rts_flags;
/* number of this process (for fast access) */
/* system privileges structure */
/* SENDING, RECEIVING, etc. */
char
char
char
char
/*
/*
/*
/*
p_priority;
p_max_priority;
p_ticks_left;
p_quantum_size;
current scheduling priority */
maximum scheduling priority */
number of scheduling ticks left */
quantum size in ticks */
struct mem_map p_memmap[NR_LOCAL_SEGS];
/* memory map (T, D, S) */
07784
07785
07786
07787
07788
07789
07790
07791
07792
07793
07794
07795
07796
07797
07798
07799
07800
07801
07802
07803
07804
07805
07806
07807
07808
07809
07810
07811
07812
07813
07814
07815
07816
07817
07818
/*===========================================================================*
*
enqueue
*
*===========================================================================*/
PRIVATE void enqueue(rp)
register struct proc *rp;
/* this process is now runnable */
{
/* Add 'rp' to one of the queues of runnable processes. This function is
* responsible for inserting a process into one of the scheduling queues.
* The mechanism is implemented here.
The actual scheduling policy is
* defined in sched() and pick_proc().
*/
int q;
/* scheduling queue to use */
int front;
/* add to front or back */
/* Determine where to insert to process. */
sched(rp, &q, &front);
/* Now add the process to the queue. */
if (rdy_head[q] == NIL_PROC) {
rdy_head[q] = rdy_tail[q] = rp;
rp->p_nextready = NIL_PROC;
}
else if (front) {
rp->p_nextready = rdy_head[q];
rdy_head[q] = rp;
}
else {
rdy_tail[q]->p_nextready = rp;
rdy_tail[q] = rp;
rp->p_nextready = NIL_PROC;
}
/* Now select the next process to run. */
pick_proc();
}
/* add to empty queue */
/* create a new queue */
/* mark new end */
/* add to head of queue */
/* chain head of queue */
/* set new queue head */
/*
/*
/*
/*
add to tail of queue */
chain tail of queue */
set new queue tail */
mark new end */
07859
07860
07861
07862
07863
07864
07865
07866
07867
07868
07869
07870
07871
07872
07873
07874
07875
07876
07877
07878
07879
07880
07881
07882
07883
07884
07885
07886
07887
07888
07889
07890
07891
07892
07893
07894
/*===========================================================================*
*
sched
*
*===========================================================================*/
PRIVATE void sched(rp, queue, front)
register struct proc *rp;
/* process to be scheduled */
int *queue;
/* return: queue to use */
int *front;
/* return: front or back */
{
/* This function determines the scheduling policy. It is called whenever a
* process must be added to one of the scheduling queues to decide where to
* insert it. As a side-effect the process' priority may be updated.
*/
static struct proc *prev_ptr = NIL_PROC;
/* previous without time */
int time_left = (rp->p_ticks_left > 0);
/* quantum fully consumed */
int penalty = 0;
/* change in priority */
/* Check whether the process has time left. Otherwise give a new quantum
* and possibly raise the priority. Processes using multiple quantums
* in a row get a lower priority to catch infinite loops in high priority
* processes (system servers and drivers).
*/
if ( ! time_left) {
/* quantum consumed ? */
rp->p_ticks_left = rp->p_quantum_size;
/* give new quantum */
if (prev_ptr == rp) penalty ++;
/* catch infinite loops */
else penalty --;
/* give slow way back */
prev_ptr = rp;
/* store ptr for next */
}
/* Determine the new priority of this process. The bounds are determined
* by IDLE's queue and the maximum priority of this process. Kernel tasks
* and the idle process are never changed in priority.
*/
if (penalty != 0 && ! iskernelp(rp)) {
rp->p_priority += penalty;
/* update with penalty */
if (rp->p_priority < rp->p_max_priority) /* check upper bound */
rp->p_priority=rp->p_max_priority;
07907
07908
07909
07910
07911
07912
07913
07914
07915
07916
07917
07918
07919
07920
07921
07922
07923
07924
07925
07926
07927
07928
07929
07930
07931
/*===========================================================================*
*
pick_proc
*
*===========================================================================*/
PRIVATE void pick_proc()
{
/* Decide who to run now. A new process is selected by setting 'next_ptr'.
* When a billable process is selected, record it in 'bill_ptr', so that the
* clock task can tell who to bill for system time.
*/
register struct proc *rp;
/* process to run */
int q;
/* iterate over queues */
/* Check each of the scheduling queues for ready processes. The number of
* queues is defined in proc.h, and priorities are set in the image table.
* The lowest queue contains IDLE, which is always ready.
*/
for (q=0; q < NR_SCHED_QUEUES; q++) {
if ( (rp = rdy_head[q]) != NIL_PROC) {
next_ptr = rp;
/* run process 'rp' next */
if (priv(rp)->s_flags & BILLABLE)
bill_ptr = rp;
/* bill for system time */
return;
}
}
}
Interrupt Handling in MINIX (1)
Informatik ∙ CAU Kiel
• Interrupt processing hardware on a 32-bit Intel PC.
© N. Luttenberger
109
Interrupt Handling in MINIX (2)
Informatik ∙ CAU Kiel
• How a hardware interrupt is processed.
© N. Luttenberger
110
Interrupt Handling in MINIX (3)
Informatik ∙ CAU Kiel
• How a system call is made.
© N. Luttenberger
111
Interrupts
Informatik ∙ CAU Kiel
• Figure 2-5 Skeleton of what the lowest level of the operating
system does when an interrupt occurs.
© N. Luttenberger
112
Clock Hardware
Informatik ∙ CAU Kiel
• A programmable clock.
© N. Luttenberger
113
Clock Software (1)
Informatik ∙ CAU Kiel
• Typical duties of a clock driver
– Maintain time of day
– Prevent processes from running longer than allowed
– Accounting for CPU usage
– Handling alarm system call by user processes
– Providing watchdog timers for parts of system itself
– Doing profiling, monitoring, and statistics gathering
© N. Luttenberger
114
Clock Software (2)
Informatik ∙ CAU Kiel
• Figure 2-48. Three ways to maintain the time of day.
© N. Luttenberger
115
Clock Software (3)
Informatik ∙ CAU Kiel
• Figure 2-49. Simulating multiple timers with a single clock.
© N. Luttenberger
116
10494
10495
10496
10497
10498
10499
10500
10501
10502
10503
10504
10505
10506
10507
10508
10509
10510
10511
10512
10513
10514
10515
10516
10517
10518
10519
10520
10521
10522
10523
10524
/*===========================================================================*
*
do_clocktick
*
*===========================================================================*/
PRIVATE int do_clocktick(m_ptr)
message *m_ptr;
/* pointer to request message */
{
/* Despite its name, this routine is not called on every clock tick. It
* is called on those clock ticks when a lot of work needs to be done.
*/
/* A process used up a full quantum. The interrupt handler stored this
* process in 'prev_ptr'. First make sure that the process is not on the
* scheduling queues. Then announce the process ready again. Since it has
* no more time left, it gets a new quantum and is inserted at the right
* place in the queues. As a side-effect a new process will be scheduled.
*/
if (prev_ptr->p_ticks_left <= 0 && priv(prev_ptr)->s_flags & PREEMPTIBLE) {
lock_dequeue(prev_ptr);
/* take it off the queues */
lock_enqueue(prev_ptr);
/* and reinsert it again */
}
/* Check if a clock timer expired and run its watchdog function. */
if (next_timeout <= realtime) {
tmrs_exptimers(&clock_timers, realtime, NULL);
next_timeout = clock_timers == NULL ?
TMR_NEVER : clock_timers->tmr_exp_time;
}
/* Inhibit sending a reply. */
return(EDONTREPLY);
}
Feedback for this Chapter
Informatik ∙ CAU Kiel
• Well understood –
easy material
• Mostly understood –
material is ok
• Hardly understood –
difficult material
© N. Luttenberger
118