CS604 Highlighted Handouts Lectures 19-45 by Masters

Operating Systems [CS-604] Lecture No. 18 and 19

Lecture No. 18 and 19

ƒ Lectures 18 and 19 on Virtual TV

Summary ƒ Process Synchronization: the basic concept

ƒ Solutions for the Critical Section Problem ƒ 2-Process Critical Section Problem solutions

Process Synchronization Concurrent processes or threads often need access to shared data and shared resources. If there is no controlled access to shared data, it is often possible to obtain an inconsistent state of this data. Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes, and hence various process synchronization methods are used. In the producer-consumer problem that was discussed earlier, the version only allows one item less than the buffer size to be stored, to provide a solution for the buffer to use its entire capacity of N items is not simple. The producer and consumer share data structure ‘buffer’ and use other variables shown below:

#define BUFFER_SIZE 10 typedef struct

} item; item buffer[BUFFER_SIZE]; int in=0; int out=0;

The code for the producer process is:

while(1)

/*Produce an item in nextProduced*/ while(counter == BUFFER_SIZE); /*do nothing*/ buffer[in]=nextProduced; in=(in+1)%BUFFER_SIZE; counter++; The code for the consumer process is:

while(1)

while(counter==0); //do nothing nextConsumed=buffer[out]; out=(out+1)%BUFFER_SIZE; counter--; /*Consume the item in nextConsumed*/

Both producer and consumer routines may not execute properly if executed concurrently. Suppose that the value of the counter is 5, and that both the producer and the consumer execute the statement counter++ and counter- - concurrently. Following the execution of these statements the value of the counter may be 4,5,or 6! The only correct result of these statements should be counter= =5, which is generated if the consumer and the producer execute separately. Suppose counter++ is implemented in machine code as the following instructions: MOV R1, counter INC R1 MOV counter, R1 whereas counter- - maybe implemented as: MOV R2, counter DEC R2 MOV counter, R2 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. 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 will be 4, where the correct result should be 5. The value of count could also be 6 if producer executes MOV counter, R1 at the end. The reason for this state is that we allowed both processes to manipulate the variable counter concurrently. A situation like this, where several processes access and manipulate the same data concurrently and the outcome of the manipulation depends on the particular order in which the access takes place, is called a race condition. To guard against such race conditions, we require synchronization of processes. Concurrent transactions in a bank or in an airline reservation (or travel agent) office are a couple of other examples that illustrates the critical section problem. We show interleaving of two bank transactions, a deposit and a withdrawal. Here are the details of the transactions: ƒ Current balance = Rs. 50,000 ƒ Check deposited = Rs. 10,000 ƒ ATM withdrawn = Rs. 5,000

The codes for deposit and withdrawal are shown in Figure 18.1.

Figure 18.1 Bank transactions—deposit and withdrawal

Here is what may happen if the two transactions are allowed to execute concurrently, i.e., the transactions are allowed to interleave. Note that in this case the final balance will be Rs. 45,000, i.e., a loss of Rs. 5,000. If MOV Balance,A executes at the end, the result will be a gain of Rs. 5,000. In both cases, the final result is wrong.

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

Critical Section: A piece of code in a cooperating process in which the process may updates shared data (variable, file, database, etc.). Critical Section Problem: Serialize executions of critical sections in cooperating processes. When a process executes code that manipulates shared data (or resource), we say that the process is in its critical section (for that shared data). The execution of critical sections must be mutually exclusive: at any time, only one process is allowed to execute in its critical section (even with multiple processors). So each process must first request permission to enter its critical section. The section of code implementing this request is

Balance

D W

DEPOSIT · MOV · A, Balance · ADD · A, Deposited · MOV · Balance, A · WITHDRAWAL · MOV · B, Balance · SUB · B, Withdrawn · MOV · Balance, B