Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Os module 2 c


Published on

Published in: Business, Technology
  • Be the first to comment

Os module 2 c

  1. 1. The OS as a gatekeeper
  2. 2. Objective To discuss various mechanisms to ensure the orderly execution of cooperating processes that share a logical address space so that data is consistently maintained.
  3. 3. Concept of concurrency Existence of several simultaneous processes. May be observed in situations like:  Multi-user OS where different users execute programs concurrently  Single-user OS where input/output devices go simultaneously with program execution  Some processors whose activities are concurrent, example, fetch next instruction is done simultaneously with the execution of an instruction.
  4. 4. bounded buffer PRODUCER CONSUMERwhile (true) { while (true) { /* produce an item and put in while (count == 0) nextProduced */ do nothing while (count == BUFFER_SIZE) nextConsumed = buffer [out]; do nothing; out = (out + 1) % BUFFER_SIZE; buffer [in] = nextProduced; count--; in = (in + 1) % BUFFER_SIZE; /* consume the item in count++; nextConsumed */} }
  5. 5. Atomic Operation The statements count ++ and count -- must be performed atomically. Atomic operation means an operation that completes in its entirety without interruption. May not function correctly when executed concurrently.
  6. 6. Atomic Operation If both the producer and consumer attempt to update the buffer concurrently, the assembly language may get interleaved Interleaving depends upon how the producer and consumer processes are scheduled.
  7. 7. Atomic Operation count++ could be implemented as MOV AX, COUNT register1 = count INC AX register1 = register1 + 1 MOV COUNT, AX count = register1 count-- could be implemented as MOV BX, COUNT register2 = count DEC BX register2 = register2 - 1 MOV COUNT, BX count = register2
  8. 8. Now consider this interleaving… Consider this execution interleaving with “count = 5” initially:  S0: producer execute register1 = count {register1 = 5}  S1: producer execute register1 = register1 + 1 {register1 = 6}  S2: consumer execute register2 = count {register2 = 5}  S3: consumer execute register2 = register2 - 1 {register2 = 4}  S4: producer execute count = register1 {count = 6 }  S5: consumer execute count = register2 {count = 4}
  9. 9. Race Condition Situation where several processes access and manipulate shared data concurrently. The final value of the shared data depends upon which process finishes last. To prevent race conditions, concurrent processes must be synchronized.
  10. 10. The Critical Section (CS) Problem Consider n processes all competing to use some shared data. Each process has a code segment, called critical section in which shared data is accessed. Ensure that when one process is executing in its critical section, no other process is allowed to execute in its critical condition.
  11. 11. The Critical Section (CS) Problem Execution of critical sections by the processes is mutually exclusive in time. Design protocol:  Each process must request permission to enter its CS (entry section)  The CS is followed by an exit section  The remaining code is in the remainder section.
  12. 12. Solution to Critical-Section Problem1.Mutual Exclusion2.Progress3.Bounded Waiting
  13. 13. Solution to Critical-Section Problem1. Mutual Exclusion - If process Pi is executing in its critical section, then no other processes can be executing in their critical sections CS P1 P2 P n
  14. 14. Solution to Critical-SectionProblemProgress - If no process is executing in its critical section and there exist some processes that wish to enter their critical section, then the selection of the processes that will enter the critical section next cannot be postponed indefinitely. CS P P 2 1 P
  15. 15. Solution to Critical-SectionProblem1. Bounded Waiting - No process should wait arbitrarily long to enter its CS. CS P P 2 1 P n
  16. 16. Note: No assumptions are made about relative process speeds or number of CPU’s A process in one CS should not block others in entering a different CS.
  17. 17. Sample Scenario – Milk IssueTime Person A Person B3:00 Look in fridge, Out of milk -------------3:05 Leave for store -------------3:10 Arrive at store Look in fridge, Out of Milk3:15 Buy Milk Leave for store3:20 Leave store Arrive at store3:25 Arrive home, put milk away Buy milk3:30 ------------- Leave Store3:35 ------------- Arrive home, oops
  18. 18. Observation Someone gets milk, but not EVERYONE (too much milk!) This shows that when cooperating processes are not synchronized, they may face unexpected “timing errors” Mutual Exclusion - ensures that only one process (or person) is doing a thing at one time, thus avoiding data inconsistency. All others should be prevented from modifying shared data until the current process finishes. E.g. only one person buys milk at a time.
  19. 19. Solution 1 – Attempt to computerize MilkBuyingPROCESS A AND B This solution works for someIf (NOmilk) people because the first{ three lines are performed if (NOnote) ATOMICALLY but does { not work otherwise. Leave note; Buy milk; What happens when the 2 Remove note; processes execute } concurrently?}
  20. 20. Solution 2 – Attempt to use two notes PROCESS A PROCESS BLeave (NOTEa); Leave (NOTEb);If (NO_NOTEb) If (NO_NOTEa){ { if (NOmilk) Buy Milk; if (NOmilk) Buy Milk;} }Remove (NOTEa); Remove (NOTEb); WHAT CAN YOU SAY ABOUT THIS SOLUTION?
  21. 21. Solution 3: PROCESS A PROCESS BLeave (NOTEa); Leave (NOTEb)If (NOnoteB) While (NOTEa) do{ nothing; if (NOmilk) Buy Milk;} if (NOmilk) Buy Milk;Remove (NOTEa); Remove (NOTEb); In case of tie, who will buy first?
  22. 22. Critique for Solution 3 Process B will always be the first to buy the milk in case of a tie. Process B consumes CPU cycles while waiting. More complicated if extended to many processes.
  23. 23. Algorithm Template do { ENTRY SECTION – Each process must request ENTRY_SECTION permission to enter its CS CRITICAL_SECTION EXIT_SECTION EXIT SECTION – Process leaves the CS thereby informing other processes Remainder_Section that the CS is free for some other process to enter } while (TRUE)
  24. 24. Two Process SolutionAlgo 1: Strict Alteration Shared var Turn <either a or b> PROCESS A PROCESS Brepeat repeat While (turn==B) do While (turn==A) do nothing; nothing; <critical section A> <critical section B> Turn = B; Turn = A;until false until falseWhich of the following requirement is violated? Mutual Exclusion Progress Bounded Waiting
  25. 25. Algorithm 2 Shared Var pAinside, pBinside; FALSE PROCESS A PROCESS BWhile (TRUE) { While (TRUE) { While (pBinside) do While (pAinside) do nothing; nothing; pAinside = True; pBinside = True; <critical section A> <critical section B> pAinside = False; pBinside = False;} }Which of the following requirement is violated? Mutual Exclusion Progress Bounded Waiting
  26. 26. Algorithm 3 Shared Var pAtrying, pBtrying : FALSE PROCESS A PROCESS BWhile (TRUE) { While (TRUE) { pAtrying = True; pBtrying = True; While (pBtrying) do While (pAtrying) do nothing; nothing; <critical section A> <critical section B> pAtrying = False; pBtrying = False;} }Which of the following requirement is violated? Mutual Exclusion Progress Bounded Waiting
  27. 27. Dekker’s Algorithm - Elegant solution to mutual exclusion problem Shared var pAtrying pBtrying = False PROCESS A PROCESS BWhile (TRUE) { While (TRUE) { pAtrying = True; pBtrying = True; While (pBtrying) While (pAtrying) if (turn==B) { if (turn==A) { pAtrying = False; pBtrying = False; while (turn==B) do nothing; while (turn==A) do nothing; pAtrying = True pBtrying = True } } <critical section> <critical section> turn==B; turn==A; pAtrying = False; pBtrying = False;} }
  28. 28. Peterson’s Algorithm: Much simpler than Dekker’s Algorithm Shared var pAtrying pBtrying = False PROCESS A PROCESS BWhile (TRUE) While (TRUE){ { pAtrying = True; pBtrying = True; turn= B; turn= A; While (pBtrying && turn ==B) While (pAtrying && turn ==A) do nothing; do nothing; <critical section A> <critical section A> pAtrying = False; pBtrying = False;} }
  29. 29. Note Both Dekker’s and Peterson’s algorithms are correct but they only work for 2 processes, similar to the last solution of the “too-much- milk” problem.
  30. 30. Multiple Process Synchronization Solution Hardware Support – special instructions Many CPU’s today provide hardware instructions to read, modify and store a word atomically. Most common instructions with this capability are:  TAS – (Test and Set ) – Motorolla 68k  CAS – (Compare and Swap) – IBM 370 and Motorola 68k  XCHG – (exchange) –x86
  31. 31. Mutual Exclusion with Test-&-Set(TAS) Shared data:boolean TestAndSet boolean lock = false;(boolean &target) Process Pi{ do { boolean rv = target; while (TestAndSet(lock)) do target = true; nothing( ); return rv;} <critical section> lock = false; remainder section }
  32. 32. Mutual Exclusion with SWAP and XCHGAtomically swap two Shared data (initialized to false):variables. boolean lock;void Swap(boolean &a, boolean waiting[n]; boolean &b) Process Pi do {{ key = true; boolean temp = a; while (key == true) a = b; Swap(lock,key); b = temp; critical section} lock = false; remainder section }
  33. 33. Multiple Process SynchronizationSolution The basic idea is to be able to read the contents of a variable (memory location) and set it to something else all in one execution cycle hence not interruptible. The use of these special instructions makes the programming task easier and improves efficiency.
  34. 34. Semaphores Synchronization tool that does not require busy waiting Semaphore S – integer variable Two standard operations modify S: wait() and signal()
  35. 35. A Semaphore… Essentially an integer S (initially S>0) and a queue of processes, initially empty Synchronization variable (guard) that takes on non-negative integer values with only two atomic operations
  36. 36. Two Atomic OperationsWait (S) PROBEREN:  While s ≤ 0 do no_op; Probe/Test  S--Signal (S) VERHOGEN:  S++ release “make higher”
  37. 37. Solution to too much milk usingsemaphore Process A & B Semaphore OkToBuyMilk = 1; Wait (OkToBuyMilk); If (NoMilk) { Buy Milk; } Signal (OkToBuyMilk)
  38. 38. Critical Section of n Processes Shared data: semaphore mutex (initially 1) do{ wait (mutex); < critical section > signal (mutex); remainder section }while (true)
  39. 39. Critique: CS of n Processes The above algorithm requires busy-wait. To overcome busy waiting, the process will block itself (placed in the waiting - queue associated with the semaphore)Define a semaphore as a record typedef struct { int value; struct process *L; } semaphore;
  40. 40. Example #1: There are 6 Synchronize the execution of the processes waiting two CPUs: in the ready queue CPU1: CPU2: (P1,P2…P6) P1; P4; Let us assume that wait (s1);  P5 can only be P2; P5; executed if P1 and P2 have already signal (s1); completed their wait (s2); tasks  P3 will only be P3; P6; executed if P6 is signal (s2); finished
  41. 41. Exercise #2: Consider the following code which is being executed by 3 CPU’s. This program computes the value of X using the Quadratic formula. Synchronize the execution of the CPU’s by using semaphore.
  42. 42. X = -B± √(B2 – 4 A C) Exercise #2 Codes: 2ACPU1: Readln (C); CPU2:Readln (A); FourAC = 4*A*C;TwiceA = A + A; If (FourAC > BSquare); ImaginaryReadln (B); SquareRoot = sqrt(abs(Bsquare – FourAC)Bsquare = B * B; Root1 = (MinusB + SquareRoot)/TwiceA;MinusB = -1 * B; Root2 = (MinusB - SquareRoot)/TwiceA;CPU3:If (Imaginary) writeln (“No real roots”)Else writeln (“the roots are”, root1, root2”)
  43. 43. Solution to Exercise 2 X = -B± √(B2 – 4 A C) 2A CPU1: Readln (C); CPU2: Readln (A); Wait(S1); Signal(S1); FourAC = 4*A*C; TwiceA = A + A; Wait(S2); Readln (B); If (FourAC > BSquare) then Imaginary =TRUE; Bsquare = B * B; SquareRoot = sqrt(abs(Bsquare – FourAC) Signal (S2); Wait(S3); MinusB = -1 * B; Root1 = (MinusB + SquareRoot)/TwiceA; Signal (S3); Root2 = (MinusB - SquareRoot)/TwiceA; Signal (S4); Wait (S4); CPU3 If (Imaginary) writeln (“No real roots”) Else writeln (“the roots are”, root1, root2”)
  44. 44. Possible uses of semaphores Mutual Exclusion – Initializes the semaphore to one (1)  Example: Wait (Mutex); < Critical section; > Signal (Mutex);
  45. 45. Possible uses of semaphores Synchronization of cooperating processes (signalling) – initializes the semaphore to zero.  Example Pi: Pj … … … … A wait (flag) Signal (flag) B
  46. 46. Possible uses of semaphore Managing multiple instances of a resource - Initializes the semaphore to the number of instances.
  47. 47. Types of semaphores Binary – semaphore with an integer value of 0 or 1 Counting – semaphore with an integer value ranging between 0 and an arbitrarily large number. - Initial value represents the number of units of the critical resources that are available. - Also known as general semaphore.
  48. 48. Classical Problems of Synchronization
  49. 49. Bounded-Buffer Problem: Two processes share a common, fixed size buffer. One of them, the producer puts information into the buffer, and the other, the consumer, takes out information from the buffer. When the producer wants to put a new item in the buffer but it is already full then allow the producer to sleep to be awakened when the consumer has removed one or more items. Similarly to the consumer, it goes to sleep if the buffer is empty until the producer puts something in the buffer.
  50. 50. shared data semaphore full = 0, empty = n, mutex = 1; Producer: Consumer:do { do { … wait ( full ) produce an item in nextp wait ( mutex ); … … remove item from buffer to wait ( empty ); nextc wait ( mutex ); … … signal ( mutex ); add nextp to buffer signal ( empty ); … … signal ( mutex ); consume item in nextc signal ( full ); …} while (TRUE); } while (TRUE);
  51. 51. Readers-Writers Problem This problem models access to a database with many competing processes wishing to read and write into it (imagine an airline reservation system). It is possible to have many processes reading the database at the same time (for query purposes). But if one process is writing (modifying), no other process shall access to the database, not even readers. With this condition in mind, how will you program the reader and writers?
  52. 52. Illustration: Readers and Writers Writers Area wrt Readers Area Critical section wrt
  53. 53. Readers-Writers: SolutionTypes Algorithm 1: Readers have higher priority than writers Algorithm 2: Writers have higher priority than readers
  54. 54. Algorithm #1: Readers have higher priority than writers If a writer appears while several readers are in the database, the writer must wait. If new readers keep appearing so that there is always at least one reader in the database, the writer must keep waiting until no more readers are interested in the database.
  55. 55. Solution to Readers/Writers:Algorithm #1 shared data semaphore mutex = 1, wrt = 1; int readcount = 0; Readers:Writers: do { wait ( mutex );do { readcount + +; wait(wrt); if ( readcount == 1 ) wait ( wrt ); … signal ( mutex ); … writing is performed reading is performed … … signal(wrt); wait ( mutex ); readcount - -;} while (TRUE) if (readcount == 0 ) signal ( wrt ); signal ( mutex ): } while (TRUE)
  56. 56. Algorithm 2: How about if we prioritize Writers over readers? Reprogram the above codes. Seatwork…. Writers have higher priority than readers
  57. 57. Dining-Philosophers Problem Five philosophers spend their lives thinking and eating. Philosophers share a common circular table surrounded by five chairs, each belonging to one philosopher. At the center of the table, there is a bowl of rice, and the table is laid with five single chopsticks.
  58. 58. Dining-Philosophers cont… When a philosopher thinks, he does not interact with his colleagues. When a philosopher gets hungry, he tries to pick up two chopsticks that are closest to him. Philosopher could pick up only one chopstick at a time. Obviously, he cannot pick up a chopstick that is already in the hand of his neighbor. When a hungry philosopher has his both chopsticks, he eats without releasing them. When he is finished, he puts down the chopsticks and starts thinking again.
  59. 59. Dining-Philosophersdiagram 0 4 1 3 2
  60. 60. Dining Philosophers: Initial Solution Shared data semaphore chopstick[5]; {Initially all values are 1} Philosopher i: do { wait ( chopstick [ i ] ) { his left chopstick} wait ( chopstick [ ( i + 1) % 5 ] ) { his right chopstick} … eat … signal ( chopstick [ i ] ); 0 4 signal ( chopstick [ ( i + 1) % 5 ] ); 0 … 1 4 think … 1 2 3 3 } while (TRUE); 2Question: What is wrong with this solution?
  61. 61. Solution for Dining Philosophers…Shared data: state [ 5 ] of (thinking, hungry, eating); // init to all thinking// self [ 5 ]: semaphore; { init to all 0 } mutex: semaphore; { init to 1 } left = (i + 4) % 5; { left neighbor } right = (i + 1) % 5; { right neighbor }
  62. 62. Solution for Dining Philosophers…Philosopher ( i ) { void test ( int i ) { if ( (state [ left ] ! = eating) &&state [ i ] = hungry; (state [ i ] == hungry) &&wait ( mutex ); (state [ right ] != eating)) { test [ i ]; state [ i ] = eating;signal (mutex); signal (self [ i ] );if (state [ i ] != eating ) } wait ( self [ i ] ); } void putdown ( int i ) { … eating … state [ i ] = thinking; wait ( mutex ); wait ( self [ i ] ); putdown [ i ]; signal ( mutex ); // test left and right neighbors} test ( left ); test ( ( right ); }
  63. 63. Sleeping – BarbersProblem: A barber shop consists of a waiting room with 5 chairs and the barber room containing the barber chair. If no customer to serve, the barber goes to sleep to be awakened by the customer. If a customer enters the barber shop but all chairs are occupied, the customer leaves the shop; otherwise he sits in one of the free chairs. Write the program to coordinate the actions of the barber and the customer.
  64. 64. Sleeping – Barbers Solution Shared data: customer = 0, barber = 0, mutex = 1; int waiting = 0; CHAIR = 5;Barber: Customer:while (TRUE) { while ( TRUE ) { wait ( customer ); wait ( mutex ); wait ( mutex ); if ( waiting < CHAIR) { waiting - -; waiting + +; signal ( barber ); signal ( customer ); signal ( mutex ); signal ( mutex ); .... wait ( barber ); cut hair(); …..} get haircut(); } else signal ( mutex); }
  65. 65. Exercise #1: Discuss the correctness of the Use_resource( ) function below for two process solution:int free = TRUE;use_resource ( ){ while ( ! free ); /* wait */ free = TRUE; /* use the resource – CRITICAL SECTION */ free = FALSE;}
  66. 66. Exercise #2: Discuss the correctness of the Use_resource( ) function below for two process solution: char buffer [ n ]; int full, empty; { initially full = empty = TRUE }empty_buffer( ) fill_buffer( ){ { while ( ! full ) do nothing( ); while ( ! empty ) do nothing( ); full = TRUE; empty = TRUE; /* critical section */ /* critical section */ empty ( buffer ); fill (buffer ); empty = FALSE; full = FALSE;} }
  67. 67. Exercise #3: Crossing BaboonsProblem There are two groups of baboons, one from the east and the other from the west. A one-way bridge is attached between the east cave where the east baboons live and west cave where the west baboons reside. Whoever group reaches the foot of the bridge first, will cross the bridge first signaling the other group not to cross. With this condition in mind, how will you synchronize the action of the two groups of baboons to cross the bridge?
  68. 68. Exercise #4:Cigarette-SmokerProblem There are three smoker processes and one agent process. Each smoker continuously rolls a cigarette and then smokes it. But to roll and smoke a cigarette, the smoker needs three ingredients: tobacco, paper, and matches. One of the smoker processes has paper, another has tobacco, and the third has matches. Agent has an infinite supply of all three materials. He places two of the ingredients on the table. The smoker who has the remaining ingredient then makes and smokes a cigarette, signaling the agent on completion. The agent then puts out another two of the three ingredients and the cycle repeats. Write a program to synchronize the agent and the smokers.
  69. 69. End of Presentation