Upload
hiram-spence
View
25
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Review: Process Management. Objective: Enable fair multi-user, multiprocess computing on limited physical resources Security and efficiency Process: running program + context Process Control Block: Contains Process Context Register content Memory address space PC I/O Status. - PowerPoint PPT Presentation
Citation preview
Review: Process Management
• Objective: – Enable fair multi-user, multiprocess
computing on limited physical resources– Security and efficiency
• Process: running program + context• Process Control Block: Contains
Process Context• Register content• Memory address space• PC• I/O Status
Review: Process Management
• Multicomputing is achieved by timeslicing: Every process runs for a while until time is up
• Interrupt driven(2 Types), PCB is stored and retrieved
• 5 State model: new, running, ready, waiting,terminated
• multiple queues in which processes reside during lifetime
Diagram of Process States
new terminated
Queue: waiting
Queue: ready running
I/O or event waitI/O or event completion
interrupt
admitted exit
scheduler
Review UNIX Commands
• telnet machine: login to UNIX computer• ps: show all processes that were started
– ps -u username : all processes started by user
• top: show all processes running on the computer• kill id : Stop running process with id• nohup: make process immune to high level
interrupts• nice +int process: change the priority of a
process• man command: get information about command
Inter Process Communication
• Passing information sequentially between 2 processes (simplest case)– Result of P1 becomes at termination the
input to P2
• Passing information concurrently between 2 running processes
• Use of shared resources (such as printer queue)
Tools for sequential communication
• Redirect – > saves the output (whatever would
come to the screen) into a file– >> appends the output to a file– Example: print >tmp
• Pipe– | hands the output directly to the next
process
Example• See the 9823th line of a file
– head -n file: command that shows the first n lines of file
– head -n file: command that shows the last n lines of file
• 1) Store the first 9823 temporarily in a file and than look at the last line– head -9823 file>tmp– tail -1 tmp
• 2)Pass results directly using pipe– head -9823 file|tail -1
Communication between processes:
Sharing• Simplest method: any 2 processes can use
shared file that both processes can access• However, only one process at a time can
have write access • Parent-child processes can have shared
variables– a C program can start of new processes (fork)
that have access to all global variables
Use of shared resources• Example: 2 unrelated processes want to
print to the same printer• Printer collects jobs in a printer queue • (lpq -Pprinter shows you all entries in the
queue)• A queue works like an array. Each entry is a
file that has to be printed. Processes can submit a file by appending it to the array. The printer takes jobs out from the lower end of the array.
• Global variable LAST keeps track of end of the array
Problem of Sharing: Inconsistency
• Multiprogramming can lead to inconsistency in case of shared resources
• P1 and P2 want to print, P1 is running and P2 is next in the ready queue
• P1 loads the current value of LAST into register R1
• P1 gets interrupted by scheduler because time is up
• P2 starts running and loads LAST into R3• P2 stores filename in array(R3), increments R3
and stores R3 into LAST
Inconsistency II
• P2 gets interrupted by scheduler and P1 starts running (remember, OS will restore all register values)
• P1 will store its filename at array(R1) believing that R1 is the current value of LAST and overwrite the filename stored by P2
• P1 increments R1 and saves the value to LAST
• P2’s file will never be printed!
Problems of Sharing: Deadlock
• Deadlock: Processes are waiting for resources held by another
• P1: lock(x) lock(y)
• P2: lock(y) lock(x)
• P1 can’t finish since it is waiting for resource y• P2 can’t finish since it is waiting for resource x• Neither of both ever unlocks the one it has
Race Conditions
• Whenever sharing of resources can lead to inconsistencies or deadlock
• Problem: Very hard to debug, not reproducible
• Heart of the problem is that between a test/load of a resource and the update there could be an interrupt
• Solution: atomic instruction or “uninterruptable” parts of code
The Dining Philosophers
Plate with food
Fork
Philosophers
• 5 Philosophers either think or eat• If a philosopher gets hungry he tries
sequentially to obtain 2 forks, one from his right, one from the left
• How do you make sure that they don’t starve?
Solutions 1: Test and Set
• Many processors offer a TSL instruction• TSL R1, LOCKLAST• It reads the value and during the same instruction
sets it to 1.• Now there can’t be an interrupt between the load
and the store as we had in the printer queue• If R1 is 1, the process will wait, if it is 0 it means
that the resource is available and now locked by P1
• This simple test can be used before altering LAST
Solution 2: Semaphores
• The concept of semaphores extends the idea of test and set to an integer value.
• A semaphore is a variable that can be incremented or decremented without interrupt
Solution 3: Critical Block• If multiple resources are needed as in the
deadlock case, we have to ensure, that either all resources are allocated or if only one missing none of them.
• This operation of locking all has to be immune to interrupts
• A critical block is a clock of instruction during which a program is immune to interrupts
• Note: this is a dangerous game and you don’t want to leave this to the user to implement! What happens if it contains a infinite loop?
Solution 4: Detect and Recover
• All previous attempts aimed at prevention• Sometimes it is easier and safer to allow
for the possibility of deadlocks • Deadlock detection: Dependency graph of
resources has cycles• Graph for example:
• In case of deadlock, OS prevents second process to allocate resource that produces a cycle
X Y
P1
P2
Summary Solutions• Inconsistency can be avoided by ensuring
uninterrupted blocks of instructions• Solutions might involve hardware support
(if there is a test and set instruction that is supported by the CPU design)
• Software support can avoid an interrupt by changing the responsiveness to interrupts in critical sections
• Software can detect deadlock cases and resolve them
Appendix: More UNIX
• more file: show content of file• ls: show all files in that directory• head -n file: Show first n lines of file• tail -n file: Show last n lines of file• > redirect output into new file• >> append redirected output to new
file• | pipe output into process