Cs problem [repaired]
Upcoming SlideShare
Loading in...5
×
 

Cs problem [repaired]

on

  • 745 views

 

Statistics

Views

Total Views
745
Views on SlideShare
745
Embed Views
0

Actions

Likes
0
Downloads
14
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cs problem [repaired] Cs problem [repaired] Presentation Transcript

  • CRITICAL SECTIONPROBLEM
  • CS Problem● When one process is executing in its critical section, then no process is allowed to execute in its critical section, thus the execution of CS by the processes is mutually exclusive in time
  • CS Problemdo{entry section Critical SectionExit section Remainder section}while(1);
  • CS problem● A solution to CS problem must satisfy ● Mutual exclusion: if process Pi is executing in its CS, then no other processes can be executing in their CS ● Progress: if no process is executing in its CS and some processes want to enter thier CS, then only those processes that are not executing in their remainder section can participate in the decision on which will enter its CS next, and this selection cannot be postponed indefinitely ● Bounded Waiting: There exists a bound on the number of times that other processes are allowed to enter their CS after a process has made a request to enter its CS and before that is granted
  • Two process solution for CS● Assume there are only two processes P0 and P1 at a time.● For convenience, when presenting Pi, we use Pj to denote the other process, that is j=1-i
  • Algorithm 1Do{ While (turn != i); Critical section Turn =j; Remainder section }while(1); if turn==i, then process Pi is allowed to execute CS ● Mutual exclusion is satisfied, but the progress is not satisfied ● If turn==0 and P1 is ready to enter CS, P1 cannot do, eventhough P0 may be in its remainder section
  • Algorithm 2Do{ flag[i] = true; while(flag[j]) Critical section flag[i]=false; Remainder section; }while(1);
  • Algorithm 2● Boolean flag[2];● If flag[i] is true, then P1 is allowed to enter its CS.● Mutual exclusion is satisfied and progress is not satisfied● P0 sets flag[0]=true;● P1 sets flag[1]=true;● Both P0 and P1 are looping forever in their respective while statements.
  • Algorithm 3● The processes share two variables● Boolean flag[2]● Int turn;● Initial values of flag[0] and flag[1] is false and turn value either 0 or 1 (immaterial)● All the three are satisfied ● Progress ● Mutual exclusion ● Bounded waiting
  • Algorithm 3Do{ flag[i]=true; turn=j; while(flag[j] && turn ==j); Critical section flag[i]=false; Remainder section}while(1);
  • Algorithm 3● Pi can enter its CS only when either flag[j]=false and turn=i● And if P0 and P1 change the flag[0] and flag[1] simultaneously to true and wanted to execute its CS, then turn =0 or 1 can happen only one at a time, so progress is satisfied.
  • Semaphores● Two atomic operations● P – wait – proberen (Dutch)● V – signal – verhogen● Pseudocode is● wait(S) While (S<=0) ;//no operation S--;● }
  • SemaphoresSignal (S) { S++; } ● Modification to the integer value of the semaphore in the wait and singal operations. ● That is when one process changes the semaphore value, no other process can simultaneously modify that same semaphore value.
  • Semaphore implementationtypedef struct {Int value;Struct process *L;}semaphore;each semaphore has an integer value and list of processes. When a process must wait on a semaphore, it is added to the list of processes.● A signal operation removes one process from the list of waiting processes and awakens that process
  • Semaphore implementationVoid wait(semaphore S){ S.value--; if(S.value <0){ Add this process to S.L; Block(); }}
  • Semaphore implementationVoid signal(Semaphore S){ S.value++; if(S.value <=0){ Remove a process P from S.L; wakeup(P); }}
  • Deadlock Situations• Mutual exclusion. At least one resource must be held in a non sharable mode; that is, only one process at a time can use the resource. If another process requests that resource, the requesting process must be delayed until the resource has been released.• Hold and wait. A process must be holding at least one resource and waiting to acquire additional resources that are currently being held by other processes.
  • Deadlock• No preemption. Resources cannot be preempted; that is, a resource can be released only voluntarily by the process holding it, after that process has completed its task.• Circular wait. A set { P0 , Pl, ... , P11 } of waiting processes must exist such that Po is waiting for a resource held by P1, P1 is waiting for a resource held by P2, ... , Pn-1 is waiting for a resource held by P,v and P11 is waiting for a resource held by Po.
  • Resource Allocation Graph• The sets P, K and E:• P == {P1, P2, P3}• R== {R1, R2, R3, ~}• E == {Pl -> Rl P2-> R3, Rl->P2, R2->P2, R2-> Pl, R3-> P3}• Resource instances:• One instance of resource type R1• Two instances of resource type R2
  • Resource Allocation Graph
  • Resource Allocation Graph• One instance of resource type R3• Three instances of Resource R4• Process states: • Process P1 is holding an instance of resource type R2 and is waiting for an instance of resource type R1 . • Process P2 is holding an instance of R1 and an instance of R2 and is waiting for an instance of R3. • Process P3 is holding an instance of R3nces of resource type R4
  • Resource Allocation Graph• One instance of resource type R3• Three instances of Resource R4• Process states: • Process P1 is holding an instance of resource type R2 and is waiting for an instance of resource type R1 . • Process P2 is holding an instance of R1 and an instance of R2 and is waiting for an instance of R3. • Process P3 is holding an instance of R3nces of resource type R4
  • Resource Allocation Graph
  • Resource Allocation Graph• P1 ->R1-> P3-> R2-> P1 (P4 may release R2 so that the cycle breaks)
  • Handling Deadlocks• We can use a protocol to prevent or avoid deadlocks, ensuring that the system will never enter a deadlocked state.• We can allow the system to enter a deadlocked state, detect it, and recover.• We can ignore the problem altogether and pretend that deadlocks never occur in the system. (used in windows and Unix OS)
  • Deadlock prevention• Mutual Exclusion • Handles non-sharable resource • Read only files are the good examples, so any process can use that resource, since it is sharable • But printers are non sharable, they cannot be denied since printers are intrinsically non sharable
  • Deadlock prevention• Hold and Wait • Whenever a process request any resource, it should not hold any other resource • Before a process begins its execution, all resource allocated to it. • But when the process needs any new resource during its execution, it should release the other resources. • Starvation is possible in this case, as some process will wait indefinitely to use a resource. • Also resource utilization is low, that is the resources are unused for a long period. • Example: if a process wanted to copy some files from a DVD to disk and then sort the files and printing it. A Process may request DVD and disk, once the copying is done, it may request the Printer rather than locking everything in the beginning.
  • Deadlock prevention• No Preemption • If a process requests some resources, we first check whether they are available and we allocate them. • If they are not, we check whether they are allocated to some other process that is waiting for additional resources. If so, we preempt the desired resources from the waiting process and allocate them to the requesting process. If the resources are neither available nor held by a waiting process, the requesting process must wait. While it is waiting, some of its resources may be preempted, but only if another process requests them. • This protocol is often applied to resources whose state can be easily saved and restored later, such as CPU registers and memory space. It cannot generally be applied to such resources as printers and tape drives.
  • Deadlock prevention• Circular Wait • To avoid deadlock with this, a number can be allotted to each resource • Any process can request the resource in terms of increasing order • For example F(tape)=1, F(disk)=5, F(printer) =12, a process which need tape and printer can request only tape first and then the printer. Till that time some other process can use the printer • While releasing the resource also, the processes will release in the descending order of Numbers.
  • Dining Philosophers Algorithm
  • Dining Philosophers AlgorithmSemaphore chopstick[5]={1};Int I;Room=4;Void philosopher(int i){While(TRUE){Think();Wait(room);Wait(chopstick[i]);Wait (chopstick[i+1]%5);Eat();signal(chopstick[i+1]%5);signal(chopstick[i]);Signal(room);}}
  • Deadlock Avoidance• Requires knowledge of future process resource request• Two approaches • do not start a process if its demands might lead to deadlock • Do not grant any incremental resource request to a process if this allocation might lead to deadlock
  • Deadlock AvoidanceResource R = (R1,R2,……Rn) Total amount of each resource in the systemAvailable V = (V1,V2,V3,…..Vn) Total amount of each resource not allocated to any processClaim C= Cij = requirement of process i forc11 c12 ...... c1m resource jc21 c22 ...... c2m....Cn1 cn2........cnmAllocation A = Aij = current allocation to process i ofa11 a12 ...... a1m resource ja21 a22 ...... a2m....an1 an2........anm
  • Banker’s algorithm• Safe State • Is one in which there is at least one sequence of resource allocations to processes that does not result in deadlock (All process run to completion)• Unsafe state • A state that is not safe
  • Banker’s algorithm