1 www.bookspar.

com | Website for students | VTU NOTES UNIT III SYNCHRONIZATION

4.1 BACKGROUND A situation where several processes access and manipulate the same data concurrently and the outcome of the execution depends on the particular order in which the access takes place, is called a race condition. To guard against the race condition above, we need to ensure that only one process at a time can be manipulating the same data. To make such a guarantee, we require that the processes be synchronized in some way. 4.2 THE CRITICAL-SECTION PROBLEM Consider a system consisting of n processes {P0, P1,..., Pn-1}. Each process has a segment of code, called a critical section, in which the process may be changing common variables, updating a table, writing a file, and so on. The important feature of the system is that, when one process is executing in its critical section, no other process is to be allowed to execute in its critical section. That is, no two processes are executing in their critical sections at the same time. The critical-section problem is to design a protocol that the processes can use to cooperate. Each process must request permission to enter its critical section. The section of code implementing this request is the entry section. The critical section may be followed by an exit section. The remaining code is the remainder section. The general structure of a typical process Pi, is shown in the following figure:

A solution to the critical-section problem must satisfy the following three requirements: 1. Mutual exclusion. If process P, is executing in its critical section, then no other processes can be executing in their critical sections. 2. Progress. If no process is executing in its critical section and some processes wish to enter their critical sections, then only those processes that are not executing in their remainder sections can participate in the decision on which will enter its critical section next, and this selection cannot be postponed indefinitely. 3. Bounded waiting. There exists a bound, or limit, on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted. We assume that each process is executing at a nonzero speed. However, we can make no assumption concerning the relative speed of the n processes. Two general approaches are used to handle critical sections in operating systems: (1) preemptive kernels and (2) nonpreemptive kernels. A preemptive kernel allows a process to be preempted while it is running in kernel mode. A nonpreemptive kernel does not allow a process running in kernel mode to be preempted; a kernel-mode process will run until it exits kernel mode, blocks, or voluntarily yields control of the CPU. Obviously, a nonpreemptive kernel is essentially free from race conditions on kernel data structures, as only one process is active in the kernel at a time. We cannot say the same about nonpreemptive kernels, so they

www.bookspar.com

2 www.bookspar.com | Website for students | VTU NOTES

must be carefully designed to ensure that shared kernel data are free from race conditions. Preemptive kernels are especially difficult to design for SMP architectures, since in these environments it is possible for two kernel-mode processes to run simultaneously on different processors. A preemptive kernel is more suitable for real-time programming, as it will allow a realtime process to preempt a process currently running in the kernel. Furthermore, a preemptive kernel may be more responsive, since there is less risk that a kernel-mode process will run for an arbitrarily long period before relinquishing the processor to waiting processes. 4.3 PETERSONS SOLUTION There is a classic software-based solution to the critical-section problem known as Peterson's solution. Peterson's solution is restricted to two processes that alternate execution between their critical sections and remainder sections. The processes are numbered P0 and P1. For convenience, when presenting Pi, we use Pj to denote the other process; that is, j equals 1i. Peterson's solution requires two data items to be shared between the two processes: int turn; boolean flag[2]; The variable turn indicates whose turn it is to enter its critical section. That is, if turn == i, then process Pi, is allowed to execute in its critical section. The flag array is used to indicate if a process is ready to enter its critical section. For example, if flag[i] is true, this value indicates that Pi, is ready to enter its critical section. To enter the critical section, process Pi, first sets flag[i] to be true and then sets turn to the value j, thereby asserting that if the other process wishes to enter the critical section, it can do so. If both processes try to enter at the same time, turn will be set to both i and j at roughly the same time. Only one of these assignments will last; the other will occur but will be overwritten immediately. The eventual value of turn decides which of the two processes is allowed to enter its critical section first. The following algorithm describes the structure of Pi in Petersons solution:

To prove that this solution is correct, we need to show that: 1. Mutual exclusion is preserved. 2. The progress requirement is satisfied. 3. The bounded-waiting requirement is met. To prove property 1, we note that each Pi enters its critical section only if either flag[j] == false or turn == i. Also note that, if both processes can be executing in their critical sections at

www.bookspar.com

3 www.bookspar.com | Website for students | VTU NOTES

the same time, then flag[0] == flag [1] == true. These two observations imply that P0 and P1 could not have successfully executed their while statements at about the same time, since the value of turn can be either 0 or 1 but cannot be both. Hence, one of the processes say Pj must have successfully executed the while statement, whereas Pi had to execute at least one additional statement ("turn == j "). However, since, at that time, flag[j] == true, and turn == j, and this condition will persist as long as Pi is in its critical section, the result follows: Mutual exclusion is preserved. To prove properties 2 and 3, we note that a process Pi can be prevented from entering the critical section only if it is stuck in the while loop with the condition flag[j] == true and turn == j; this loop is the only one possible. If Pj is not ready to enter the critical section, then flag [j] == false, and Pi can enter its critical section. If Pj has set flag [j] to true and is also executing in its while statement, then either turn == i or turn == j. If turn == i, then Pi will enter the critical section. If turn == j, then Pj will enter the critical section. However, once Pj exits its critical section, it will reset flag[j] to false, allowing Pi to enter its critical section. If Pj resets flag[j] to true, it must also set turn to i. Thus, since Pi does not change the value of the variable turn while executing the while statement, Pi will enter the critical section (progress) after at most one entry by Pi (bounded waiting). 4.4 SYNCHRONIZATION HARDWARE It can be stated that any solution to the critical-section problem requires a simple toola lock. Race conditions are prevented by requiring that critical regions be protected by locks. That is, a process must acquire a lock before entering a critical section; it releases the lock when it exits the critical section. This is illustrated in the following figure:

The TestAndSet () instruction can be defined as shown boolean TestAndSet(boolean *target) { boolean rv = *target; *target = TRUE; return rv; } The important characteristic is that this instruction is executed atomically. Thus, if two TestAndSet () instructions are executed simultaneously (each on a different CPU), they will be executed sequentially in some arbitrary order. If the machine supports the TestAndSet () instruction, then we can implement mutual exclusion by declaring a Boolean variable lock, initialized to false. The structure of process Pi is shown: do { while (TestAndSetLock(&lock)) ; // do nothing // critical section lock = FALSE; // remainder section }while (TRUE);

www.bookspar.com

4 www.bookspar.com | Website for students | VTU NOTES

The SwapO instruction, in contrast to the TestAndSet () instruction, operates on the contents of two words; it is defined as shown: void Swap(boolean *a, boolean *b) { boolean temp = *a; *a = *b; *b = temp; } It is executed atomically. If the machine supports the Swap () instruction, then mutual exclusion can be provided as follows. A global Boolean variable lock is declared and is initialized to false. In addition, each process has a local Boolean variable key. The structure of process Pi is shown: do { key = TRUE; while (key == TRUE) Swap(&lock, &key}; // critical section lock = FALSE; // remainder section }while (TRUE); 4.5 SEMAPHORES A semaphore S is an integer variable that, apart from initialization, is accessed only through two standard atomic operations: wait () and signal (). The wait () operation was originally termed P; signal() was originally called V. The definition of wait () is as follows: wait(S) { while S <= 0 ; // no-op S--; } The definition of signal () is as follows: signal(S) { S + + ; } All the modifications to the integer value of the semaphore in the wait () and signal () operations must be executed indivisibly. That is, when one process modifies the semaphore value, no other process can simultaneously modify that same semaphore value. In addition, in the case of wait(S), the testing of the integer value of S (S < 0), and its possible modification (S), must also be executed without interruption. Operating systems often distinguish between counting and binary semaphores. The value of a counting semaphore can range over an unrestricted domain. The value of a binary semaphore can range only between 0 and 1. On some systems, binary semaphores are known as mutex locks, as they are locks that provide mutual exclusion. We can use binary semaphores to deal with the critical-section problem for multiple processes. The n processes share a semaphore, mutex, initialized to 1. Each process Pi is organized as shown:

www.bookspar.com

5 www.bookspar.com | Website for students | VTU NOTES

do { waiting(mutex); // critical section signal (mutex) ,// remainder section }while (TRUE); We can also use semaphores to solve various synchronization problems. For example, consider two concurrently running processes: P1 with a statement S1 and P2 with a statement S2. Suppose we require that P2 be executed only after S1 has completed. We can implement this scheme readily by letting P1 and P2 share a common semaphore synch, initialized to 0, and by inserting the statements S1; signal(synch); in process P1, and the statements wait(synch); S2; in process P2. Because synch is initialized to 0, P2 will execute S2 only after P1 has invoked signal (synch), which is after statement S1 has been executed. 4.6.1 The Bounded-Buffer Problem The bounded-buffer problem is commonly used to illustrate the power of synchronization primitives. We assume that the pool consists of n buffers, each capable of holding one item. The mutex semaphore provides mutual exclusion for accesses to the buffer pool and is initialized to the value 1. The empty and full semaphores count the number of empty and full buffers. The semaphore empty is initialized to the value n; the semaphore full is initialized to the value 0. The code for the producer process is shown: do{ // produce an item in nextp ... wait(empty); wait (mutex); ... // add nextp to buffer ... signal(mutex); signal (full); }while (TRUE); The code for the consumer process is shown: do { wait (full); wait(mutex); ... //remove an item from buffer to nextc ... signal(mutex);

www.bookspar.com

6 www.bookspar.com | Website for students | VTU NOTES

signal(empty); //consume the item in nextc ... }while (TRUE); 4.6.2 The Readers-Writers Problem A database is to be shared among several concurrent processes. Some of these processes may want only to read the database, whereas others may want to update (that is, to read and write) the database. We distinguish between these two types of processes by referring to the former as readers and to the latter as writers. Obviously, if two readers access the shared data simultaneously, no adverse affects will result. However, if a writer and some other thread (either a reader or a writer) access the database simultaneously, chaos may ensue. To ensure that these difficulties do not arise, we require that the writers have exclusive access to the shared database. This synchronization problem is referred to as the readers-writers problem. In the solution to the first readers-writers problem, the reader processes share the following data structures: semaphore mutex, wrt; int readcount; The semaphores mutex and wrt are initialized to 1; readcount is initialized to 0. The semaphore wrt is common to both reader and writer processes. The mutex semaphore is used to ensure mutual exclusion when the variable readcount is updated. The readcount variable keeps track of how many processes are currently reading the object. The semaphore wrt functions as a mutual-exclusion semaphore for the writers. The code for a writer process is shown:

The code for a reader process is shown:

www.bookspar.com

7 www.bookspar.com | Website for students | VTU NOTES

4.6.3 The Dining-Philosophers Problem Consider five philosophers who spend their lives thinking and eating. The philosophers share a circular table surrounded by five chairs, each belonging to one philosopher. In the center of the table is a bowl of rice, and the table is laid with five single chopsticks. When a philosopher thinks, she does not interact with her colleagues. From time to time, a philosopher gets hungry and tries to pick up the two chopsticks that are closest to her (the chopsticks that are between her and her left and right neighbors). A philosopher may pick up only one chopstick at a time. Obviously, she cannot pick up a chopstick that is already in the hand of a neighbor. When a hungry philosopher has both her chopsticks at the same time, she eats without releasing her chopsticks. When she is finished eating, she puts down both of her chopsticks and starts thinking again.

One simple solution is to represent each chopstick with a semaphore. A philosopher tries to grab a chopstick by executing a wait () operation on that semaphore; she releases her chopsticks by executing the signal () operation on the appropriate semaphores. Thus, the shared data are semaphore chopstick[5]; where all the elements of chopstick are initialized to 1. The structure of philosopher i is shown

4.7 MONITORS A type, or abstract data type, encapsulates private data with public methods to operate on that data. A monitor type presents a set of programmer-defined operations that are provided mutual exclusion within the monitor. The monitor type also contains the declaration of variables whose values define the state of an instance of that type, along with the bodies of procedures or functions that operate on those variables. The syntax of a monitor is shown:

www.bookspar.com

8 www.bookspar.com | Website for students | VTU NOTES

The representation of a monitor type cannot be used directly by the various processes. Thus, a procedure defined within a monitor can access only those variables declared locally within the monitor and its formal parameters. Similarly, the local variables of a monitor can be accessed by only the local procedures. 4.7.1 Dining-Philosophers Solution Using Monitors This solution imposes the restriction that a philosopher may pick up her chopsticks only if both of them are available. To code this solution, we need to distinguish among three states in which we may find a philosopher. For this purpose, we introduce the following data structure: enum {thinking, hungry, eating}state [5]; Philosopher i can set the variable state [i] = eating only if her two neighbors are not eating: (state [(i+4) % 5] != eating) and (state [(i+1) % 5] != eating). We also need to declare condition self [5]; where philosopher i can delay herself when she is hungry but is unable to obtain the chopsticks she needs. The distribution of the chopsticks is controlled by the monitor dp, whose definition is shown below.(next page) Each philosopher, before starting to eat, must invoke the operation pickup (). This may result in the suspension of the philosopher process. After the successful completion of the operation, the philosopher may eat. Following this, the philosopher invokes the putdown() operation. Thus, philosopher i must invoke the operations pickup() and putdown() in the following sequence: dp.pickup(i); ... eat ...

www.bookspar.com

9 www.bookspar.com | Website for students | VTU NOTES

dp.putdown(i);

4.7.3 Implementing a Monitor Using Semaphores We now consider a possible implementation of the monitor mechanism using semaphores. For each monitor, a semaphore mut ex (initialized to 1) is provided. A process must execute wait(mutex) before entering the monitor and must execute signal (mutex) after leaving the monitor. Since a signaling process must wait until the resumed process either leaves or waits, an additional semaphore, next, is introduced, initialized to 0, on which the signaling processes may suspend themselves. An integer variable next_count is also provided to count the number of processes suspended on next. Thus, each external procedure F is replaced by wait(mutex) ; ... body of F ... if (next_count > 0) signal(next); else signal(mutex); Mutual exclusion within a monitor is ensured. We can now describe how condition variables are implemented. For each condition x, we introduce a semaphore x_sem and an integer variable x_count, both initialized to 0. The operation x. wait () can now be implemented as x_count++; if (next_count > 0) signal(next);

www.bookspar.com

10 www.bookspar.com | Website for students | VTU NOTES

else signal(mutex); wait(x_sem); x_count; The operation x. signal () can be implemented as if (x_count > 0) { next_count++; signal(x_sem); wait(next) ; next_count; }

www.bookspar.com