Concurrent Processes Rab Nawaz Jadoon

Transcription

1 Concurrent Processes Rab Nawaz Jadoon DCS COMSATS Institute of Information Technology Assistant Professor COMSATS Lahore Pakistan Operating System Concepts

2 Concurrent Processes If more than one threads exists in a system at the same time, then the threads are said to be concurrent. Two concurrent thread can execute completely independently of one another or they can execute in a cooperation. Threads that operate independently of one another but must occasionally communicate and synchronize to perform cooperative tasks are said to execute asynchronously. Asynchronism is a complex topic and more important for OS designer to answer the issues related to it. 2

3 Mutual Exclusion Consider a mail server that processes s for an organization. System that monitors the total number of mails that have been sent since the day began. Receipt of an is handled by one of several concurrent threads. Each time one of these threads receives an from a user, the thread increments a process wide share variable, mailcount, by 1. What happen if two thread wants to increment mailcount at once. 3

4 Mutual Exclusion Assume that each thread execute the following assembly language code to increment the value in mailcount. LOAD mailcount ADD 1 STORE mailcount Suppose mailcount = Suppose thread1 execute the first two instructions, thus leaving in the integer. Its time expires and loses the processor and the system context switch to thread2. 4

5 Mutual Exclusion The thread2 executes all three instructions, thus setting mailcount = Once thread1 resume, it will also update the same value in mailcount. Due to uncontrolled access to the shared variable, the system has lost track of one which should be In this case this issue may be seen minor, but a similar error occurring in mission critical application such as air traffic control could cost lives. 5

6 Solution To solve this problem an exclusive access should be granted to each thread to this shared resource. Once an access is granted to shared variable the other who wanted to access this, should be kept in waiting until one completed his work. Serializing access to the shared variable. This is called mutual exclusion. 6

7 Bounded Buffer Problem counter++ in assembly language MOV R1, counter INC R1 MOV counter, R1 counter-- in assembly language MOV R2, counter DEC R2 MOV counter, R2 7

8 Bounded Buffer Problem If both the producer and consumer attempt to update the buffer concurrently, the machine language statements may get interleaved. Interleaving depends upon how the producer and consumer processes are scheduled. 8

9 Bounded Buffer Problem Assume counter is initially 5. One interleaving of statements is: Producer: MOV R1, counter (R1 = 5) INC R1 (R1 = 6) Consumer: MOV R2, counter (R2 = 5) DEC R2 (R2 = 4) Producer: MOV counter, R1 (counter = 6) Consumer: MOV counter, R2 (counter = 4) The value of count may be either 4 or 6, where the correct result should be 5. 9

10 Race Condition: Process Synchronization The situation where several processes access and manipulate shared data concurrently, the final value of the data depends on which process finishes last. 10

11 Example Bank transactions D Balance W Deposit MOV A, Balance ADD A, Deposited MOV Balance, A Withdrawal MOV B, Balance SUB B, Withdrawn MOV Balance, B 11

12 Bank Transactions Bank transactions Current balance 50,000 Check deposited 10,000 ATM Withdrawal 5,000 12

13 Bank Transactions Check Deposit: MOV A, Balance // A = 50,000 ADD A, Deposited // A = 60,000 ATM Withdrawal: MOV B, Balance // B = 50,000 SUB B, Withdrawn // B = 45,000 Check Deposit: MOV Balance, A // Balance = 60,000 ATM Withdrawal: MOV Balance, B // Balance = 45,000 13

14 Java Multithreading: A case Study Producer/Consumer relationship in Java One thread creates data to store in shared object Second thread reads data from that object Large potential for data corruption if unsynchronized 14

15 Producer/Consumer (Java) Buffer interface used in producer/consumer examples. 15

16 Producer/Consumer (Java) Producer class represents the producer thread in a producer/consumer relationship (1 of 3). 16

17 Cont.(2 of 3) 17

18 Cont (3 of 3) 18

19 Producer/Consumer (Java) Consumer class represents the consumer thread in a producer/consumer relationship. (1 of 3) 19

20 Cont (2 of 3) 20

21 Cont (3 of 3) 21

22 Producer/Consumer (Java) UnsynchronizedBuffer class maintains the shared integer that is accessed by a producer thread and a consumer thread via methods set and get. (1 of 2) 22

23 Cont (2 of 2) 23

24 Producer/Consumer (Java) SharedBuffer class enables threads to modify a shared object without synchronization. (1 of 4) 24

25 Producer/Consumer (Java) SharedBuffer class enables threads to modify a shared object without synchronization. (2 of 4) 25

26 Producer/Consumer (Java) SharedBuffer class enables threads to modify a shared object without synchronization. (3 of 4) 26

27 Producer/Consumer (Java) SharedBuffer class enables threads to modify a shared object without synchronization. (4 of 4) 27

28 Critical sections Mutual Exclusion needs to be enforced only when threads access shared modifiable data. When a thread is accessing a share modifiable data, it is said to be in Critical Section or Critical region. To prevent the kind of errors we see earlier, the system should ensure that only one thread at a time can execute the instructions in its critical section. 28

29 Critical Section Once a thread has exited its critical section, a waiting thread may enter and execute its critical section. A thread in critical section has exclusive access to the shared modifiable data and all other threads currently requiring access to that data are kept waiting. So a thread should execute a critical section as quickly as possible. A thread must not block inside its critical section. Carefully coded to avoid infinite loops 29

30 Mutual Exclusion Primitives Indicate when critical data is about to be accessed Mechanisms are normally provided by programming language or libraries Delimit beginning and end of critical section entermutualexclusion exitmutualexclusion 30

31 Implementing ME Primitives Common properties of mutual exclusion primitives Each mutual exclusion machine language instruction is executed indivisibly i.e. once started it completes without interruption. Cannot make assumptions about relative speed of thread execution. Thread not in its critical section cannot block other threads from entering their critical sections Thread may not be indefinitely postponed from entering its critical section 31

32 Dekker s Algorithm An elegant software implementation to ME was first presented by the Dutch mathematician Dekker. Gives correct software implementation to ME that is free of deadlock and indefinite postponement. 32

33 Semaphore A semaphore is a variable (non ive integer) that, Controlling access by multiple processes to a common resource in a parallel programming environment. A useful way to think of a semaphore is as a record of how many units of a particular resource are available (without race conditions) adjust that record as units are required or become free, and if necessary wait until a unit of the resource becomes available. 33

34 Semaphore Semaphores are a useful tool in the prevention of race conditions. Semaphores which allow an arbitrary resource count are called counting semaphores, while semaphores which are restricted to the values 0 and 1 (or locked/unlocked, unavailable/available) are called binary semaphores. Same functionality that mutexes have. 34

35 Semaphore (Example) Suppose a library has 10 identical study rooms, intended to be used by one student at a time. To prevent disputes, students must request a room from the front counter if they wish to make use of a study room. When a student has finished using a room, the student must return to the counter and indicate that one room has become free. If no rooms are free, students wait at the counter until someone relinquishes a room. 35

36 Semaphore (Example) The clerk at the front desk does not keep track of which room is occupied, only the number of free rooms available. When a student requests a room, the clerk decreases this number, if available. When a student releases a room, the clerk increases this number. Once access to a room is granted, the room can be used for as long as desired, and so it is not possible to book rooms ahead of time 36

37 Semaphore (Example) In this scenario the front desk represents a semaphore, the rooms are the resources, and the students represent processes. The value of the semaphore in this scenario is initially 10 (assume). When a student requests a room he or she is granted access and the value of the semaphore is changed to 9. After the next student comes, it drops to 8, then 7 and so on. If someone requests a room and the resulting value of the semaphore is negative, they are forced to wait. 37

38 Semaphore When multiple people are waiting, they will either wait in a queue, or use Round-robin scheduling and race back to the counter when someone releases a room. Semaphore operations are commonly implemented in the nucleus of the OS where process state switching is controlled. 38

39 Fairness and safety are likely to be compromised. Important observation Requesting a resource and forgetting to release it Releasing a resource that was never requested Holding a resource for a long time without needing it Using a resource without requesting it first (or using a resource after releasing it). If processes follow these rules, multi-resource deadlock may still occur when there are different resources managed by different semaphores. 39

40 Semantic & implementation One important property of the semaphore variables is that its value cannot be changed except by using the wait() and signal() functions. Counting semaphores are equipped with two operations, V signal() and, P wait() Operation V increments the semaphore S, and, Operation P decrements it. The operations are atomic. 40

41 Semantic & implementation The value of the semaphore S is the number of units of the resource that are currently available. The P(S) operates as follows, if S > 0 then S S 1 else (wait on S) V (S) operates as follows, if (one or more processes are waiting on S) then (let of the these processes proceed) else S S+1 41

42 42