Operating Systems Lecture Notes

Lecture 2
Processes and Threads
A process is an execution stream in the context of a particular process state.
o An execution stream is a sequence of instructions.
o Process state determines the effect of the instructions. It usually includes (but is
not restricted to):
Registers
Stac
!emory (global "ariables and dynamically allocated memory)
#pen file tables
Signal management information
$ey concept: processes are separated: no process can directly affect the state of
another process.
Process is a ey #S abstraction that users see % the en"ironment you interact &ith &hen
you use a computer is built up out of processes.
o 'he shell you type stuff into is a process.
o (hen you execute a program you ha"e )ust compiled* the #S generates a process
to run the program.
o +our ((( bro&ser is a process.
#rgani,ing system acti"ities around processes has pro"ed to be a useful &ay of
separating out different acti"ities into coherent units.
'&o concepts: uniprogramming and multiprogramming.
o -niprogramming: only one process at a time. 'ypical example: .#S. Problem:
users often &ish to perform more than one acti"ity at a time (load a remote file
&hile editing a program* for example)* and uniprogramming does not allo& this.
So .#S and other uniprogrammed systems put in things lie memory%resident
programs that in"oed asynchronously* but still ha"e separation problems. #ne
ey problem &ith .#S is that there is no memory protection % one program may
&rite the memory of another program* causing &eird bugs.
o !ultiprogramming: multiple processes at a time. 'ypical of -nix plus all
currently en"isioned ne& operating systems. Allo&s system to separate out
acti"ities cleanly.
!ultiprogramming introduces the resource sharing problem % &hich processes get to use
the physical resources of the machine &hen/ #ne crucial resource: 0P-. Standard
solution is to use preempti"e multitasing % #S runs one process for a &hile* then taes
the 0P- a&ay from that process and lets another process run. !ust sa"e and restore
process state. $ey issue: fairness. !ust ensure that all processes get their fair share of the
0P-.
1o& does the #S implement the process abstraction/ -ses a context s&itch to s&itch
from running one process to running another process.
1o& does machine implement context s&itch/ A processor has a limited amount of
physical resources. 2or example* it has only one register set. 3ut e"ery process on the
machine has its o&n set of registers. Solution: sa"e and restore hard&are state on a
context s&itch. Sa"e the state in Process 0ontrol 3loc (P03). (hat is in P03/ .epends
on the hard&are.
o Registers % almost all machines sa"e registers in P03.
o Processor Status (ord.
o (hat about memory/ !ost machines allo& memory from multiple processes to
coexist in the physical memory of the machine. Some may require !emory
!anagement -nit (!!-) changes on a context s&itch. 3ut* some early personal
computers s&itched all of process4s memory out to dis (555).
#perating Systems are fundamentally e"ent%dri"en systems % they &ait for an e"ent to
happen* respond appropriately to the e"ent* then &ait for the next e"ent. 6xamples:
o -ser hits a ey. 'he eystroe is echoed on the screen.
o A user program issues a system call to read a file. 'he operating system figures
out &hich dis blocs to bring in* and generates a request to the dis controller to
read the dis blocs into memory.
o 'he dis controller finishes reading in the dis bloc and generates and interrupt.
'he #S mo"es the read data into the user program and restarts the user program.
o A !osaic or 7etscape user ass for a -R8 to be retrie"ed. 'his e"entually
generates requests to the #S to send request pacets out o"er the net&or to a
remote ((( ser"er. 'he #S sends the pacets.
o 'he response pacets come bac from the ((( ser"er* interrupting the
processor. 'he #S figures out &hich process should get the pacets* then routes
the pacets to that process.
o 'ime%slice timer goes off. 'he #S must sa"e the state of the current process*
choose another process to run* the gi"e the 0P- to that process.
(hen build an e"ent%dri"en system &ith se"eral distinct serial acti"ities* threads are a
ey structuring mechanism of the #S.
A thread is again an execution stream in the context of a thread state. $ey difference
bet&een processes and threads is that multiple threads share parts of their state. 'ypically*
allo& multiple threads to read and &rite same memory. (Recall that no processes could
directly access memory of another process). 3ut* each thread still has its o&n registers.
Also has its o&n stac* but other threads can read and &rite the stac memory.
(hat is in a thread control bloc/ 'ypically )ust registers. .on4t need to do anything to
the !!- &hen s&itch threads* because all threads can access same memory.
'ypically* an #S &ill ha"e a separate thread for each distinct acti"ity. In particular* the
#S &ill ha"e a separate thread for each process* and that thread &ill perform #S
acti"ities on behalf of the process. In this case &e say that each user process is baced by
a ernel thread.
o (hen process issues a system call to read a file* the process4s thread &ill tae
o"er* figure out &hich dis accesses to generate* and issue the lo& le"el
instructions required to start the transfer. It then suspends until the dis finishes
reading in the data.
o (hen process starts up a remote '0P connection* its thread handles the lo&%le"el
details of sending out net&or pacets.
1a"ing a separate thread for each acti"ity allo&s the programmer to program the actions
associated &ith that acti"ity as a single serial stream of actions and e"ents. Programmer
does not ha"e to deal &ith the complexity of interlea"ing multiple acti"ities on the same
thread.
(hy allo& threads to access same memory/ 3ecause inside #S* threads must coordinate
their acti"ities "ery closely.
o If t&o processes issue read file system calls at close to the same time* must mae
sure that the #S seriali,es the dis requests appropriately.
o (hen one process allocates memory* its thread must find some free memory and
gi"e it to the process. !ust ensure that multiple threads allocate dis)oint pieces of
memory.
1a"ing threads share the same address space maes it much easier to coordinate acti"ities
% can build data structures that represent system state and ha"e threads read and &rite data
structures to figure out &hat to do &hen they need to process a request.
#ne complication that threads must deal &ith: asynchrony. Asynchronous e"ents happen
arbitrarily as the thread is executing* and may interfere &ith the thread4s acti"ities unless
the programmer does something to limit the asynchrony. 6xamples:
o An interrupt occurs* transferring control a&ay from one thread to an interrupt
handler.
o A time%slice s&itch occurs* transferring control from one thread to another.
o '&o threads running on different processors read and &rite the same memory.
Asynchronous e"ents* if not properly controlled* can lead to incorrect beha"ior.
6xamples:
o '&o threads need to issue dis requests. 2irst thread starts to program dis
controller (assume it is memory%mapped* and must issue multiple &rites to
specify a dis operation). In the meantime* the second thread runs on a different
processor and also issues the memory%mapped &rites to program the dis
controller. 'he dis controller gets horribly confused and reads the &rong dis
bloc.
o '&o threads need to &rite to the display. 'he first thread starts to build its request*
but before it finishes a time%slice s&itch occurs and the second thread starts its
request. 'he combination of the t&o threads issues a forbidden request sequence*
and smoe starts pouring out of the display.
o 2or accounting reasons the operating system eeps trac of ho& much time is
spent in each user program. It also eeps a running sum of the total amount of
time spent in all user programs. '&o threads increment their local counters for
their processes* then concurrently increment the global counter. 'heir increments
interfere* and the recorded total time spent in all user processes is less than the
sum of the local times.
So* programmers need to coordinate the acti"ities of the multiple threads so that these
bad things don4t happen. $ey mechanism: synchroni,ation operations. 'hese operations
allo& threads to control the timing of their e"ents relati"e to e"ents in other threads.
Appropriate use allo&s programmers to a"oid problems lie the ones outlined abo"e.