Processes - the user view
Overview – processes: system view
a virtual address space
system view of processes
–
process state (context, resources, attributes)
–
supervisor mode execution
–
execution state
system calls
–
call gates
–
kinky processes (virtual machines and emulations)
process dispatching, switching, blocking and swapping
processes – the system view
3/5/03 - 1
–
registers, PC, PS
–
synchronous execution and asynchronous signals
system resources and services
execution state model
–
code, data, and stack segments
–
handles for system objects (e.g. files)
–
system services to manipulate those objects
processes – the system view
Processes – the system view
Process State – saved context
everything system knows is in process descriptor
the state of the process's virtual computer
process is represented by state data structures
registers
–
state to restore when process is dispatched
–
references to allocated resources
–
information to support process operations
creation (fork) and destruction (exit)
–
dispatch, block, unblock, signal
–
resource association and dissociation
processes – the system view
–
program counter, processor status word
–
stack pointer, general registers
virtual address space
characterized by its major operations
–
3/5/03 - 2
–
text, data, and stack segments
–
sizes, locations, and contents
all this is restored when the process is dispatched
–
3/5/03 - 3
this creates the illusion of continuous execution
processes – the system view
3/5/03 - 4
Process State – resource references
used by user-mode application
(local name space for resources)
processes have many resources
–
establish local context (e.g. current directory)
–
input files (e.g. /home/markk/scripts/test.sh)
–
establish local resource name space (e.g UFDs)
–
output files (e.g. X11 display=sagredo.west:0.0)
–
current working directory (e.g. /home/markk/cs111)
used by resource managers within the OS
once assigned to the process they get local names
–
unforgeable capabilities for allocated resources
–
a record of which resources were allocated
–
standard input is the file in open-file-slot number 0
–
record the current states of allocated resources
–
standard output is the file in open-file-slot number 1
–
to facilitate post-mortem resource reclamation
–
the current working directory can always be called “.”
processes – the system view
3/5/03 - 5
processes – the system view
State to support various operations
(unforgeable resource capabilities)
user programs can make up any file name they want
–
knowing the name of a file doesn't mean you can use it
–
we have to check application-supplied resource names
resource pointers in process descriptor are protected
–
process descriptors aren't accessible from user-mode
–
they can only be written by OS code, which we trust to
have done the appropriate authorization checks
–
if a resource is in the process descriptor, we can trust it
processes – the system view
3/5/03 - 7
3/5/03 - 6
scheduling state (e.g. running, ready, blocked)
identification and protection information
–
process ID, process group, parent process, ...
–
owning user, session, supplementary privileges, ...
configuration information
–
options, preferences, parameters, environment variables
interprocess communication queues
–
signals, mail-boxes, events, ...
processes – the system view
3/5/03 - 8
process descriptors – resident/non-resident
in memory
resident state
(resident process state)
on secondary storage
non-resident state
process state that could be needed at any time
process 1
in memory
–
data structures needed to signal or awaken process
process 2
process 2
on disk
information needed to schedule process
run-state, priority, statistics
process 1
–
identification information
–
communication and synchronization resources
process ID, user ID, group ID, parent ID
process 3
swapping
out
process 3
process 3
semaphores, pending signals, mail-boxes
...
processes – the system view
–
3/5/03 - 9
processes – the system view
(non-resident process state)
allocate/initialize resident process description
allocate/initialize non-resident description
execution state
saved register values, PC, PSW
–
create a virtual address space
pointers to resources process can use when running
working directory, files, network connections
–
pointers to text, data and stack segments
not needed when process is blocked
–
can swap out to free memory for other processes
processes – the system view
3/5/03 - 10
Creating a new process
information needed only when process runs
–
pointer to non-resident state
3/5/03 - 11
–
allocate memory for code, data and stack
–
load a program code and data into new segments
–
initialize a stack segment
–
set up initial registers (PC, PS, SP)
return from supervisor mode into new process
processes – the system view
3/5/03 - 12
Why support a cloning "fork" operation
Variations of process creation
copying and sharing resources is a lot of work
tabula rasa – a blank slate
–
new process with minimal resources
–
e.g. new data and stack, no open files, etc.
–
creating a "tabula rasa" process is much easier
historical reasons
fork – clone an existing process
–
parallel processing literature used a cloning fork
–
fork was only way to get parallism before threads
–
parent and child have all the same credentials
–
share the same code, copies of data and stack
–
easy to manage shared stdin, stdout, stderr
–
share all of the same open files
–
easy to set up process pipe-lines (e.g. ls | more)
–
share or copy virtually all of the same resources
–
share exclusive-access resources (e.g. tape drives)
processes – the system view
practical reasons
3/5/03 - 13
Exploiting a cloning “fork”
the OS executes in supervisor mode
int pipefds[2];
pipe(pipefds);
/* create a pipe (returns read and write descriptors) */
if (fork()) {
/* parent ... will become pgm1 */
} else {
able to execute privileged instructions
–
able update memory management registers
to create and modify process address spaces
–
/* move read end of pipe to stdin */
access data structures within the OS
application programs execute in user mode
/* load and run pgm2 */
}
processes – the system view
–
/* load and run pgm1 */
close(pipefds[0]); close(pipefds[1] ); /* close the left over descriptors */
execv(“pgm2”, 0);
able to perform I/O operations
e.g. enable, disable and return from interrupts
/* child ... will become pgm2 */
close(0); dup(pipefds[0]);
–
/* move write end of pipe to stdout */
close(pipefds[0]); close(pipefds[1] ); /* close the left over descriptors */
execv(“pgm1”, 0);
3/5/03 - 14
User vs. Supervisor mode execution
/* create the pipe “pgm1 | pgm2” */
close(1); dup(pipefds[1]);
processes – the system view
3/5/03 - 15
–
they can only execute normal instructions
–
they are restricted to the process's address space
processes – the system view
3/5/03 - 16
System Call Trap Gates
Subroutine calls vs. system calls
Application Program
called subroutines execute in user mode
–
they can't do anything the application can't do
user mode
–
there is no reason to protect access to subroutines
supervisor mode
... instr; instr; instr; TRAP; instr; instr; instr ...
system calls execute in supervisor mode
–
they enjoy all the privileges of being part of the OS
–
we cannot allow user to execute arbitrary OS code
–
OS code and data are not in process's address space
1st level trap
handler
TRAP vector table
2nd level handler
(system service
implementation)
system calls enter the OS through "call gates"
–
return to
user mode
user only has access to selected safe entry points
syscall dispatch table
processes – the system view
3/5/03 - 17
(Transition into Supervisor Mode)
hardware trap handling
processes – the system view
3/5/03 - 18
(Using traps to invoke system calls)
reserve one illegal instruction for system calls
–
use trap cause to index into trap vector table for PC/PS
–
load new processor status word, switch to supv mode
–
push PC/PS of program that cuased trap onto stack
–
call: r0 = system call number, r1 points to arguments
–
load new program counter (w/addr of 1st level handler)
–
return: r0 = return code, cc indicates success/failure
software system call trap handling
–
1 level handler pushes all other registers
define system call linkage conventions
execute the designated system call instruction
nd
–
1 level handler gathers args, selects 2 level handler
–
2nd level handler performs requested system call
processes – the system view
most computers specifically define such instructions
prepare arguments for the desired system call
st
st
–
3/5/03 - 19
OS recognizes and performs requested operation
returns to instruction after the system call
processes – the system view
3/5/03 - 20
(Returning to User Mode)
Stacking and unstacking a trap
user mode
computation
return is opposite of interrupt/trap entry
supervisor mode stack
user mode stack
growth
user-mode
PC and PS
saved
user-mode
registers
parameters
to 2 nd level
handler
–
2nd level system call handler returns to 1st level handler
–
1st level handler restores all registers from stack
–
use privileged return instruction to restore PC/PS
–
resume user-mode execution at instruction after trap
saved registers can be changed before return
return PC
stack frame
for 2 nd level
handler
–
change stacked user r0 to reflect return code
–
change stacked user PS to reflect success/failure
...
processes – the system view
3/5/03 - 21
Processes in Supervisor Mode
processes – the system view
3/5/03 - 22
Supervisor mode execution contexts
processes can execute in user or supervisor mode
–
it runs with same credentials as user-mode process
–
it still has access to same code, data, stack segments
–
it runs supervisor code, with supervisor mode privileges
each process has its own supervisor mode stack
most supervisor execution is on behalf of a process
–
runs with that process' address space and credentials
some processes only run in supervisor mode
–
system daemons (e.g. NFS, swap management)
–
these too are scheduled and can block for resources
–
allocated as part of non-resident status structure
–
a process can be blocked while in supervisor mode
–
processed on the stack of whatever process is running
–
it will resume in supervisor mode when it is unblocked
–
they are not scheduled, and cannot block for resources
interrupt handling is not associated with a process
initialization happens before any processes exist
processes – the system view
3/5/03 - 23
processes – the system view
3/5/03 - 24
Message-based system services
originally all OS used traps for system calls
Messages vs. traps: performance
the cost of using a trap to request a service
–
simple, relatively fast, exploits existing mechanisms
–
format arguments, execute trap, get results
–
50-250 instructions, plus losing the cache
the cost of using a message to request a service
many experimental OS have used messages
–
a system call to send the request
–
prepare a message describing desired request
–
a process switch to the recipient/server
–
send the message to a designated server
–
a system call to receive the request
–
server will send back a response message when done
–
a system call to send the response
–
a process switch to the requestor
–
a system call to receive the response
processes – the system view
3/5/03 - 25
Messages vs. traps: generality
who can service a trap?
–
3/5/03 - 26
Traps and system services revisited
ordinary instructions are directly executed by CPU
the OS on the CPU that received the trap
only "illegal" instructions go through the OS
who can process a message?
–
a daemon process within the local OS
–
a user-mode daemon process on the same machine
–
a server process on another node in the network
messages work well in a distributed environment
–
the client and server need not be co-located
–
if a server fails, requests can be routed to an alternate
processes – the system view
processes – the system view
3/5/03 - 27
–
execution exceptions (illegal address, zero-divide, ...)
–
system call trap instructions
–
privileged instructions executed from user-mode
what happens after the trap into supervisor mode?
–
the operating system can do what-ever it wants to do
–
it can treat the trap as an error
–
it can intrepret it as a request for some service
processes – the system view
3/5/03 - 28
Operating System emulations
Virtual Machine emulations
an OS supports a specific set of system calls
–
privileged instructions are also service requests
different OS's support different system calls
–
a system call is just a trap instruction
"requested services" are simple and well defined
OS can make each process behave like a computer
–
with a particular set of arguments (OS ABI)
–
OS maintains walls between virtual machines
–
that will be processed in a particular way
–
each user can run his own operating system
–
practical solution for "legacy" applications
one OS can emulate another OS's system calls
Performance
–
intercept same trap instructions other OS uses
–
decode same arguments, perform same operations
performance can be very good
processes – the system view
3/5/03 - 29
–
very good ... except for the privileged instructions
–
complications in compound scheduling, memory mgt
processes – the system view
3/5/03 - 30
un-dispatching a running process
Scheduling states & transitions
somehow we enter the operating system
–
di
es
qu
Re
BLOCKED
Yi
el
d
Allocate
create
sp
at
e.g. via a yield system call or a clock interrupt
the state of the process must be preserved
RUNNING
t
Exit
ch
READY
–
user mode state is already saved on stack
–
supervisor mode registers are also saved on stack
–
descriptions of address space. and pointers to code, data
and stack segments are stored in the process descriptor
yield CPU – call scheduler to select another process
processes – the system view
3/5/03 - 31
processes – the system view
3/5/03 - 32
Blocking and unblocking processes
(re-)dispatching a process
blocked/unblocked are merely notes to scheduler
decision to switch is made in supv mode
–
after state of current process has been saved
–
the scheduler has been called to yield the CPU
–
anyone can set them, anyone can change them
select the next process to be run
–
this usually happens in a resource manager
get pointer to its process descriptor(s)
–
locate and restore its saved state
–
restore code, data, stack segments
–
restore saved registers, PS, and finally the PC
when process needs an unavailable resource
change process's scheduling state to "blocked"
call the scheduler and yield the CPU
–
3/5/03 - 33
when the required resource becomes available
change process's scheduling state to "ready"
and we are now executing in a new process
processes – the system view
blocked processes are not eligible to be dispatched
notify scheduler that a change has occurred
processes – the system view
Primary and Secondary Storage
primary = main (executable) memory
3/5/03 - 34
Why we swap
make the best use of a limited amount of memory
–
primary storage is expensive and very limited
–
a process can only execute if it is in memory
–
only processes in primary storage can be run
–
max number of processes is limited by memory size
–
if a process isn't READY, it doesn't need to be in memory
–
swap it out and make room for some other process
secondary = non-executable (e.g. Disk)
–
blocked processes can be moved to secondary storage
–
swap out code, data, stack and non-resident context
–
make room in primary for other "ready" processes
returning to primary memory
–
process is copied back when it becomes unblocked
processes – the system view
3/5/03 - 35
improve CPU utilization
–
when there are no READY processes, CPU is idle
–
CPU idle time means reduced system throughput
–
more processes to chose from means less idle time
processes – the system view
3/5/03 - 36
scheduling states with swapping
for the next lecture
di
es
qu
Yi
el
d
Re
BLOCKED
Sw
ap
create
sp
at
there will be a quiz on this material
ch
Allocate
Sw
-o
ap
read chapter 7
RUNNING
t
Exit
-i
ut
next lecture – CPU scheduling
READY
n
SWAPPED
OUT
processes – the system view
3/5/03 - 37
key points
process descriptors
–
resident/non-resident context, state, resources
–
process creation (clone and tabula-rasa)
context switching
–
general activties and costs, detailed steps
user and supervisor mode execution
–
system call trap gates, reasons, how they work
–
message based requests, costs and benefits
–
virtual machines and OS emulations
dispatching, yielding, blocking, swapping
processes – the system view
3/5/03 - 39
–
measuring scheduler performance
–
pre-emptive and non-preemptive scheduling
–
algorithms: fcfs, shortest job first, round-robin
–
performance, load, over-load, graceful degradation
processes – the system view
3/5/03 - 38