Concurrency Control Flashcards
(30 cards)
3 Concurrency contexts
- Multiple applications, process time shared 2. Structured applications 3. OS structures
Critical resources(CR)
Memory, shared I/O (printer), shared devices
Critical section (CS)
portion of program that uses critical resources
Concurrency Cases (3 broad activities)
- communication among processes 2. sharing and competing for resources 3. synchronization of activities of multiple processes
OS design and management issues of concurrency
- OS must be able to track active processes using PCB 2. OS allocate and deallocate resources for each process 3. OS must protect data and physical resources of each process against unintended interface by other processes 4, Results of process must be independent of speed of execution
how do processes interact
- unaware of each other 2. indirectly aware (share access to some I/O 3. directly aware of each other
principle strategies of concurrency
single processor - processes interleaved multiple processor, multiprogramming - processes overlapped
data coherence, consistency
maintenance of global variables and relationships between them
how do we maintain data coherence
sequential program execution
3 control problems of concurrency
- mutual exclusion - only one program at a time allowed 2. deadlocks - p1 has r1 needs r2; p2 has r2 needs r1 3, starvation - p1 has r1; p3 may get but p2 starved
requirements for ME (mutual exclusion)
- ME must be enforced 2. Process that halts in non CS must do so without interfering with other processes 3. Process requiring CS can’t be delayed indefinitely 4. When no process in CS, process that requests entry must be allowed to enter 5. No assumptions about relative process speeds or number of processes 6. Process remains inside CS for finite time delay
implementation of ME 3 approaches
software approach special purpose machine instructions (turn, test and set) semaphores
1st software approach to ME implementation (turn)
address reserved for turn shared variable Process 0 Process 1 while (turn != 0) ….. /*do nothing*/; while (turn != 1) /*CS*/ /* do nothing*/; turn = 1; /*CS*/ turn = 0;
analysis of turn approach
ME guaranteed with problems toggle issue - processes strictly alternate, pace dictated by slower if one process fails, other stalls
2nd software approach to ME (Boolean flags)
flag[0] for P0; if TRUE, it’s in CS flag[1] for P1 if FALSE not in CS reset own flag after leaving CS each process may examine other’s flag (not change it)
analysis of Boolean flag approach
ME not guaranteed P0 executes the while flag[1] false P1 executes the while flag[0] false BOTH can enter the CS at the same time…..!!!!!!! If flag[1] = TRUE and P1 fails; then system hangs If flag[1]=FALSE and P1 fails; then it is ok . NOT independent of relative process execution speeds…. A process can change its state after the other process has checked it, but before the other process can enter into critical section…
correct software solutions to ME
Decker’s algorithm Peterson’s algorithm Combine flag and turn approaches Need to observe state of both processes, which process has right to insist on entering CS
Decker’s algorithm
void P0() //need same method for 1() { while(TRUE) //main while loop { flag[0] = TRUE; //turn on your own flag while(flag[1]) //test for P1’s flag { If (turn == 1) //if P1 is active then { flag[0] = FALSE; //turn off your own flag while (turn == 1) //wait for P1 to release /*do nothing, stay here*/; flag[0] = TRUE; //you got the turn now } /* CS */; turn = 1; //give turn to other guy flag[0] = FALSE; //turn off your flag /* remainder */ } //end of test for P1 } //end of main while } //
Peterson’s algorithm
boolean flag[2]; int turn; //MAIN PROGRAM void main() { flag[0] = FALSE; flag[1] = FALSE; turn = 0; parabegin (P0, P1); } void P0() //duplicate method for p1() { while(TRUE) //main while loop { flag[0] = TRUE; //turn on your own flag // so that P1 can’t get in turn = 1; //Give a chance to P1 while(flag[1] && turn == 1) //test for P1’s flag and his turn { /*do nothing, stay here*/; } /* CS */; flag[0] = FALSE; //turn off your flag /* remainder */ } //end of main while } //end of P0
major issue with all software support for ME
not scalable, multiplies turns and flags
hardware support for ME - single processor
with single processor, disable interrupts; guarantees ME while(TRUE) { /* disable interrupts */ * CS */ /*enable interrupts */ /*remainder*/ }
analysis of hardware approach to ME
ok for single CPU; not good solution, need to have control breaks and so on
Hardware approach - ASM Test and Set Special machine instructions Be able to write for final
Test and Set Instruction Reading and writing with one instruction in an atomic fashion (not subject to interrupts) boolean testset (int i) { If (i==0) { i = 1; return TRUE; } else { return FALSE; } }; /*program ME */ const int n = /*number of processes */ int bolt; void P(int i) { while (TRUE) { while (!testset(bolt)) /* do nothing, testset was not successful*/; /* CS testset was successful */ bolt = 0; /* release the bolt*/ /*remainder*/; } //end of main while }//end of P void main() { Bolt = 0; parabegin ((P(1), P(2), …, P(n)); }
Summary of Test and Set (ASM)
Reads and writes at the same time Go and test lock on CS If available, lock it N processes have their own test and set on one CS (say the printer ) Atomic (no interrupts); must be done at assembly level Wastes CPU