1. © Janice Regan, CMPT 300, May 2007 0 CMPT 300 Introduction to Operating Systems Mutual Exclusion

2. © Janice Regan, CMPT 300, May 2007 1 Implementation  Now we have the basic ideas we need  How do we actually implement mutual exclusion?  There are several approaches  Interrupt disabling  Lock variables  Strict alternation  Special instructions  Peterson’s solution  Message passing  Semaphores and Mutexes  Monitors

3. © Janice Regan, CMPT 300, May 2007 2 General form, mutual exclusion  No matter how we implement mutual exclusion, conceptually the following happens in each process using the resource protected my mutual exclusion NonCriticalRegion() StartCriticalRegion() CriticalRegion() EndCriticalRegion() NonCritical Region()

4. © Janice Regan, CMPT 300, May 2007 3 General form, mutual exclusion  We must now think about how the implement the StartCriticalRegion() and EndCriticalRegion() operations  Must consider how multiple processes running these at the same time interact  What happens to a request to StartCriticalRegion() if another process’s critical region is executing when the request occurs (drop, queue …)?  How do we assure that a process cannot access a resource allocated to another process?

5. © Janice Regan, CMPT 300, May 2007 4 Interrupts: hardware based solution  Interrupts may be generated by hardware devices and by software instructions (for many instruction sets)  Some interrupts can be disabled, others cannot  Most interrupts may be blocked (disabled), these are called maskable interrupts.  Usually there are few interrupts that cannot be disabled (non maskable interrupts NMI) these include software/hardware commands like reset that need to be available regardless of whether interrupts are masked.

6. © Janice Regan, CMPT 300, May 2007 5 Nested interrupts  What happens when an interrupt occurs while the system is processing another interrupt.  The interrupt generates a signal which is  acknowledged immediately by the hardware supporting the interrupt queue (PIC), and placed in the interrupt queue  Ignored while the CPU is busy. In this case the device requesting the interrupt may retransmit the request periodically until it receives an acknowledgment  Ignore while the CPU is busy, lose all such interrupts

7. © Janice Regan, CMPT 300, May 2007 6 Common question?  If interrupts are disabled within a critical section how does the CPU know when I/O is done? It will not get the interrupt from the I/O device.  No, it will get the interrupt (for most systems). To explain why we need to understand two facts  When you disable interrupts you can disable a particular interrupt or set of interrupts necessary to protect your shared resource  Interrupts can also be generated in software

8. © Janice Regan, CMPT 300, May 2007 7 Disable Interrupt/s  When you disable/enable interrupts  You can disable/enable all possible interrupts in the system You may need to re-enable particular interrupts that you need to complete your critical region  You can disable/enable a particular interrupt or set of interrupts necessary to protect your shared resource  When you disable all interrupts you prevent the present process from being swapped out of the CPU by the scheduler (no timer interrupts to end its time slice)

9. © Janice Regan, CMPT 300, May 2007 8 Disabling Interrupts: step by step  Have each process entering a critical region take each of the following steps  Run StartCriticalRegion(). Begin by disabling all interrupts Enable hardware interrupts needed for I/O to be completed within the critical region Assure that during I/O waits the scheduler is not called  Run CriticalRegion(), safely reading/writing shared memory. You can be sure that no other process will change the shared memory while the present process works with it because there is no way to switch to another process.  Run EndCriticalRegion() Immediately before completion re-enable interrupts

10. © Janice Regan, CMPT 300, May 2007 9 Problems with disabling interrupts  Must be very efficient in placing the minimum amount of work inside the critical region. Minimize increase in turnaround time  Since each process must wait for the read or write of the protected shared memory the CPU is idle during those waits reducing the utilization of the CPU while the I/O hardware is busy.  Works on a single processor, not a multiprocessor system (multicore?).  Interrupts are disabled on only one processor, the other processors can still access the shared information, mutual exclusion is not assured, so order of process execution may matter

11. © Janice Regan, CMPT 300, May 2007 10 Other possible drawbacks  User processes StartCriticalRegion() and EndCriticalRegion() must have direct access to instructions to disable interrupts. Such instructions may be privileged mode instructions.  In a multiprocessing system with competing processes this is not desirable, one process could disable interrupts and run to completion making other processes wait.  In a multiprocessing system where processes are cooperating to accomplish a single goal. (Like software to run your cell phone) this can be a very useful and practical solution

12. © Janice Regan, CMPT 300, May 2007 11 Locking variables: A software based solution?  Use a shared variable to control access to shared memory resources (do not disable interrupts)  Define a shared variable, say lock1  If the value of the variable lock1 is 1 the process must wait to access the resource  If the value of the variable lock1 is 0 the process sets it to 1 then accesses the resource  Upon completion the process sets lock1 to 0

13. © Janice Regan, CMPT 300, May 2007 12 Locking Variable int lock1 = 0 // =1 is locked void main() { while (lock1 == 1) { } lock1 = 1; CriticalSection(); lock1 = 0; NonCriticalSection(); }

14. © Janice Regan, CMPT 300, May 2007 13 Example of problem: locking  Process 1 is interrupted after the while statement  Process 2 runs and encounters a critical section, sets lock to 1 and starts processing the critical section  Process 2 enters a wait state (say a wait for input) and process 1 is again allowed to run  Process 1 sets lock to 1 (no change) then begins its critical section. Two critical sections are now being executed at the same time!! Mutual exclusion is violated

15. © Janice Regan, CMPT 300, May 2007 14 Problems  The lock variable needs mutual exclusion too!  Exactly the same problem as we saw with the print queue example. The lock variable can be changed by another process after it is set and before it is used by the present process.

16. © Janice Regan, CMPT 300, May 2007 15 Fixing the lock  The problem is caused by a need for mutual exclusion on the lock variable  How can we remove that problem?  Use multiple lock variables, one for each process  Enforce strict alternation between two processes  Use special atomic instruction for access to lock variables

17. © Janice Regan, CMPT 300, May 2007 16 Special instructions  Some CPUs have special instructions that can help with protecting lock variables  A single non-divisible instruction is supplied to do the following. Since the instruction is atomic (cannot be interrupted) there is no problem caused by interrupts in the test and set sequence bool testSet( int i) { if( i == 0 ) { i = 1; return true; } else { return false; }

18. © Janice Regan, CMPT 300, May 2007 17 Test and set instruction: Use  To use the testSet instruction while(true) { while(!testSet(lock)) { } CriticalSection(); lock = 0; NonCriticalSection(); }  Uses busy waiting, any lock using busy waiting (spin waiting) is known as a “spin lock”

19. © Janice Regan, CMPT 300, May 2007 18 Problems: Test and set instruction  Use of the testSet() instruction can cause deadlock due to priority inversion  Consider a low priority process Plow and a high priority process Phigh  A priority inversion occurs when Phigh is blocked (forced to wait for Plow) by Plow Plow is running and has entered a critical region for a particular resource Phigh becomes ready to run preempts Plow and begins to run Phigh tries to enter a critical region for the resource locked by Plow and is blocked until Plow finishes with the protected shared resource (If the Plow cannot run because it is lower priority this causes a deadlock)

20. © Janice Regan, CMPT 300, May 2007 19 Problems: Test and set instruction  Requires the inefficiency of busy waiting  Starvation is possible  Consider a system where 3 processes are sharing a resource  When process 1 exits from its critical sect ion both process 2 and process 3 are waiting for the resource (they both want to enter their own critical sections)  The next process that is given access to the resource is chosen arbitrarily, say process 2 is chosen  Before process 2 finishes with the resource processes 5.and 6 also reach a point where they want to enter a critical region to use the same resource  Processes can keep arriving and being chosen to run their critical regions before process 2, it is possible that process 2 will never get its turn.