Overview. Processes, Thread Management, Basic IPC Memory Management Resource Sharing & Inter-Process Interactions Issues and Problems (Deadlocks, CS, ME…) Task Orderings (Scheduling issues and solutions) Algorithmic Solutions (Races, ME…) Program Level Solutions (Semaphores, Monitors)
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Lots and lots of processes and threads in the OS – how to orchestrate them so things run without contentions? ie. how to give each process dedicated access (ME) to shared execution areas (CS)
- Does it help if a process starts writing in the same space where another process is reading from?
- Does it help if a new process gets allocated the same resource (registers, variables, code segments etc ) already allocated to an existing process (before that process gets to finish)?
- Does it help if a slow process blocks other processes from executing?
Four key conditions need to hold to provide mutual exclusion
Deadlocks (& Livelocks & Starvation)
A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause
Deadlock can arise if all four conditions hold simultaneously
D has T, wants U
C has U, wants T
A B C
Non-competing A, B, C request patterns – Kernel decides actual allocation
Deadlock Occurrence: Strict Request Order
Deadlock Avoidance via Change of Request Order by OS!
Requires OS to see entire pattern first (non on-the-fly allocation) and select order!
(o) (p) (q)
Conceptually nice but naive: (a) Requests are often dynamic, (b) Tasks usually
have precedence relations, priorities, timing durations etc: Partial Order & Scheduling Algs
4 General strategies for dealing with deadlocks
- do careful resource allocation
- negate one of the four necessary conditions for deadlock
x of Type 1, y of Type 2…
P1 holds C1jresources
and requests R1jresources
Resource is either allocated or available
Allocated + Available =‘s Total Existing
Rowi ≤ Rowj iff each element(Rowi) ≤ element(Rowj)
e.g., ( 2 1 0 0) ≤ (2 2 0 0) or (2 1 0 0)
Find R (Rowi )≤ A i.e., enough resources available to continue no deadlock
P3, runs; New A = (2 2 2 0)
Next P2 runs with New A = (4 2 2 1)
Q: How often to check for free resources? Check =‘s New Process!
Costly… plus works only for static & a priori known resource requests
Requires that the system has some additional a priori information available.
Printer access by both (not possible by ME!)
Shaded area ME condition prevents entry there. Thus, if
trajectory goes into Box(I1,I2,I6,I5) it only leads to deadlock Box @t
indicates “unsafe” state.
-Req. printer --
--Req. plotter --
Plotter access by both (not possible!)
Process B executing
---------Req. plotter -------
----------Req. printer ------
Scheduler chooses to
run A or B
A instruction executing
Process A executing
Safe: If there is a scheduling order that satisfies all processes even if they
request their maximum resources at the same time?
* Keep in mind that only 1 process can execute at a given time!
Available Resources = 10(Maximal Concurrent Req: 20)
(a) (b) (c) (d) (e)
B runs with 2; asks for (2 more) for max 4; gets/finishes, C runs with 2; asks for max; gets/finishes; A runs
Safe access path starting at (a)
Safe =‘s Guarantee for finishing exists
Unsafe access starting from (b)
Note: This is not a deadlock – just that the “potential” for a deadlock exists IF A/C ask for the max. If they ask for <max, the system works just fine!
(a) (b) (c) (d)
“Potential” deadlock state as both A or C
can ask for 5 resources
and only 4 are currently free!
(a) safe (b) safe (c)
With Free 1, cannot satisfy
any max A, B, C request
regardless of request order:
“potential for deadlock” if
all would make requests!
Safe as can satisfy max C for progress &
delay A, B, C. On C finishing, Free = 4
Allowing B or D to ask for max (delay A)
And then finish max A
Safe as can satisfy max A, B, C or D
one at a time – safe order exists!
Avoiding deadlock by design of permitted safe states!
(in reality, criteria for giving “credits/loans” can be based on (a) past behavior
of processes (b) bursty traffic analysis (likelihood of run on the bank?), (c) constrained maxima : these form
the classical basis for router/server loading decisions for web services!!! DoS attacks make use of this)
Remember the Deadlock Detection Approach?
Is this algorithm useful in practice?
Is it realistic for a process to declare its max resource needs in advances?
If R (eg D) whose unmet resources
are less than A, exists progress
B req Scanner; 1 < 2; OK, allows
D,A, E, C to finish
E wants Scanner (after B); (1020)
reduced to (1000) holding up
Others defer E
(Called C in prior Alg) P = (5 3 2 2)
Constrain the ways in which requests can be made.
Option 1: Process entitled to only 1 resource at a time; Has to
give up resource if it needs another one. Say, process wants to
copy large file from tape to printer – so ??? Fails