1. INTERPROCESS COMMUNICATION Inter process communication (IPC) is a capability supported by operating system that allows one process to communicate with another process. The processes can be running on the same computer or on different computers connected through a network. IPC enables one application to control another application, and for several applications to share the same data without interfering with one another. IPC mechanism called Dynamic Data Exchange.

2. S hared-Memory, Race Conditions, and Mutual Exclusion A critical problem occurring in shared-memory system is that two or more processes are reading or writing some shared variables or shared data, and the final results depend on precisely who runs and when. Such situations are called Race Conditions. In order to avoid race conditions we must find some way to prevent more than one process from reading and writing shared variables or shared data at the same time, i.e., we need the concept of Mutual Exclusion, where one process is in use is sharing a variable, and the other process is excluded from doing the same thing.

3. Serialization The key idea in process synchronization is serialization. This means that we have to go to some pains to undo the work we have put into making an operating system perform several tasks in parallel. The scheduler can be disabled for a short period of time, to prevent control being given to another process during a critical action like modifying shared data. The protocol ensures that processes have to queue up to gain access to shared data.

4. Mutex: Mutual Exclusion When two or more processes must share some object, an arbitration mechanism is needed so that they do not try to use it at the same time. For example; two processes attempting to update the same bank account must take turns; if each process reads the current balance from some database, updates it, and then writes it back, one of the updates will be lost. This can be solved if there is some way for each process to exclude the other from using the shared object during critical sections of code. Thus the general problem is described as the mutual exclusion problem. Mutual exclusion can be achieved by a system of locks. A mutual exclusion lock is colloquially called a mutex.

5. Lost Update Lost update: Occurs when a transaction say (B) updates the same data being modified by another transaction say (A) in such a way that (B) reads the value of (A) at time 2 prior to the write operation of A at time 3 and the updated value of A is lost. Table: 3.1 Example on Lost Update Problem This example in table 3.1 shows that the write operation at time 3 is overwritten by the write operation at time 4. The transactions are from the same or from the different sites or locations and the lost update problem returns an erroneous value of A.

6. 6 The critical section must ENFORCE ALL THREE of the following rules: Mutual Exclusion: No more than one process can execute in its critical section at one time. Progress: If no one is in the critical section and someone wants in, then those processes not in their remainder section must be able to decide in a finite time who should go in. Bounded Wait: All requesters must eventually be let into the critical section. PROCESS SYNCHRONIZATION Critical Sections

7. Critical Section The key to preventing trouble involving shared storage is find some way to prohibit more than one process from reading and writing the shared data simultaneously. That part of the program where the shared memory is accessed is called the critical section. To solve the critical section problem, three criteria are there: 1.Mutual Exclusion: If process P1 is executing in its critical section then no other process can be executing in their critical section. 2.Progress: If no process is executing in its critical section and there exists some process that wish to enter their critical section, then the selection of the process that will enter the critical section next cannot be postponed indefinitely. 3.Bounded Waiting: A bound must exist on the number of times that other process 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.

8. 6: Process Synchronization8 FLAG TO REQUEST ENTRY: Each processes sets a flag to request entry. Then each process toggles a bit to allow the other in first. This code is executed for each process i. Are the three Critical Section Requirements Met? PROCESS SYNCHRONIZATION Two Processes Software do { flag [i]:= true; turn = j; while (flag [ j ] and turn == j) ; critical section flag [i] = false; remainder section } while (1); Shared variables F boolean flag[2]; initially flag [0] = flag [1] = false. F flag [i] = true  P i ready to enter its critical section This is Peterson’s Solution

9. Bakery’s Algorithm Bakery algo to critical section problem for n processes as follows: Before entering its critical section, process receives a number. Holder of the smallest number enters the critical section. If processes P i and P j receive the same number, if i < j, then Pi is served first; else P j is served first. The numbering scheme always generates numbers in increasing order of enumeration; i.e., 1,2,3,3,3,3,4,5....

10. State Lamport’s Bakery algo with solution The basic idea of a Bakery algorithm is that of a bakery. On entering the bakery, customers take tokens. Wherever has the lowest tokens gets service next. Service means entry to the critical section. While(T) { Choosing [ownID]=T; //*Receive a token token[ownID]=max[token[0],token[1],…….token[n-1]+1; {Choosing [ownID]=F; //*Wait for Turn For(othersID=0; othersID<n; thus ID++) while(choosing[othersID]); while(token[othersID]!=0 && (token[othersID]), othersID)< (token(ownID,ownID)); Critical Section(); // *Enter Critical section Token[OwnID]=0; //* Leave Critical Section }

11. What is a semaphore A semaphore is a variable. There are 2 types of semaphores: Binary semaphores Counting semaphores Binary semaphores have 2 methods associated with it. (up, down / lock, unlock) Binary semaphores can take only 2 values (0/1). They are used to acquire locks. When a resource is available, the process in charge set the semaphore to 1 else 0. Counting Semaphore may have value to be greater than one, typically used to allocate resources from a pool of identical resources. It is used to implement bounded concurrency problems.

12. SEMAPHORES in critical section problem The effective synchronization tool often used to realise mutual exclusion in more complex systems are semaphores. A semaphore S is an integer variable which can be accessed only through two standard atomic operations: wait() and signal(). The definition of the wait and signal operation are: wait(S) signal(S) { while S ≤ 0 {S++; };S- - } All the modifications to the integer value of the semaphore in the above two operations must be executed indivisibly. Semaphore can be used in this way Do{waiting(mutex); //*critical section Signal(Mutex); //* Remainder Section } While(True);

13.  A queue is used to hold processes waiting on the semaphore the process that has been blocked the longest is released from the queue first (FIFO) Strong Semaphores the order in which processes are removed from the queue is not specified Weak Semaphores

14. Difference between strong and weak semaphore Strong Semaphores: unblock the longest waiting process and guarantee freedom from starvation. Strong Semaphores: maintains FIFO queue Weak Semaphores: unblock without regard to order Weak Semaphores: maintains no guaranteed order of the queue

15. Define two operations permitted on a Semaphore The semaphore has only two operations P() and V() P() waits until value>0 then decrement V() increment, waiting up a thread Waiting in P() if necessary

16. Implement the indivisibility criteria of the two operations on the semaphore The two operations are indivisible or atomic. For the V() operation to be indivisible its execution must not be implemented by any P() or v() operations executed by other process on the same semaphore. For the P() operations, there are two separate execution branches based on the condition to be checked. The indivisibility of P() and V(), operations are necessary to guarantee the correctness for the intended purpose of semaphore.

17. 17 Producer/Consumer Problem A large class of concurrency control problems. These problems are used for testing nearly every newly proposed synchronization scheme. Producer–Consumer processes are common in operating systems. The problem definition is that, a producer (process) produces the information that is consumed by a consumer (process). For example, a compiler may produce assembly code, which is consumed by an assembler. A producer can produce one item while the consumer is consuming another item. The producer and consumer must be synchronized. These problems can be solved either through unbounded buffer or bounded buffer.

18. Producer/Consumer Problem(Cont.) With an unbounded buffer The unbounded-buffer producer- consumer problem places no practical limit on the size of the buffer.The consumer may have to wait for new items, but the producer can always produce new items; there are always empty positions in the buffer. With a bounded buffer The bounded buffer producer problem assumes that there is a fixed buffer size. In this case, the consumer must wait if the buffer is empty and the producer must wait if the buffer is full.

19. Producer/Consumer Problem(Cont.) Shared Data char item; //could be any data type char buffer[n]; semaphore full = 0; //counting semaphore semaphore empty = n; //counting semaphore semaphore mutex = 1; //binary semaphore char nextp,nextc;

20. Producer/Consumer Problem(Cont.) Producer Process Do { produce an item in nextp wait (empty); wait (mutex); add nextp to buffer signal (mutex); signal (full); } while (true)

21. Producer/Consumer Problem(Cont.) Consumer Process Do { wait( full ); wait( mutex ); remove an item from buffer to nextc signal( mutex ); signal( empty ); consume the item in nextc; }

22. Readers and Writers Problem The readers/writers problem is one of the classic synchronization problems. This problem has two types of clients accessing the shared data. The first type, referred to as readers, only wants to read the shared data. The second type, referred to as writers, may want to modify the shared data. There is also a designated central data server or controller. It enforces exclusive write semantics; if a writer is active then no other writer or reader can be active. The server can support clients that wish to both read and write. The readers and writers problem is useful for modeling processes which are competing for a limited shared resource.

23. Readers and Writers Problem(Cont.) Structure of a writer process While (T) //* loop for ever { Wait(wrt); //*waiting is performed Signal (wrt); //*writing is performed }

24. Readers and Writers Problem(Cont.) Structure of a reader process Reader() { While (T) //* loop for ever Wait(mutex); //*waiting is performed Read count + +; If (Read count )==1 wait(wrt) signal(mutex); //*Reading is performed Wait(mutex); Read count - -; If (Read count )==0 signal(wrt); signal(mutex); }

25. Dining Philosophers Problem Five philosophers sit around a circular table. In the centre of the table a large bowl of rice is placed. A philosopher needs two chopsticks to eat. Only 5 chop sticks are available and a chopstick is placed between each pair of philosophers. They agree that each will only use the chopstick to his immediate right and left. From time to time, a philosopher gets hungry and tries to grab the two chopsticks that are immediate left and right to him. When a hungry philosopher has both his chopsticks at the same time, he eats without releasing his chopsticks. When he finishes eating, he puts down both his chopsticks and starts thinking again.

26. Dining Philosophers Problem(cont.) Semaphore fork [5]={1}; /* Number of philosphers */ Semaphore room={4}; Void philosopher (int i) { While (true){ Think(); Wait(room); Wait(fork[i]); Wait (form[(i+1) mod 5]); Eat(); Signal(fork[(i+1) mod 5]); Signal(fork[i]); Signal(room); } Void main() { Parbegin ( Philosopher(0), Philosopher(1), Philosopher(2), Philosopher(3), Philosopher(4)); }

27. Race condition is a situation in which multiple processes read and write a shared data item and the final result depends on the relative timing of their execution The final result depends on the order of execution – the “loser” of the race is the process that updates last and will determine the final value of the variable

28. LOCKS Locks are another synchronization mechanism. A lock has got two atomic operations (similar to semaphore) to provide mutual exclusion. These two operations are Acquire and Release. A process will acquire a lock before accessing a shared variable, and later it will be released. A process locking a variable will run the following code: Lock-Acquire(); critical section Lock-Release(); The difference between a lock and a semaphore is that a lock is released only by the process that have acquired it earlier. As we discussed above any process can increment the value of the semaphore. To implement locks, here are some things you should keep in mind: To make Acquire () and Release () atomic Build a wait mechanism. Making sure that only the process that acquires the lock will release the lock.

29. MONITORS Monitors are the alternatives of the semaphores to address the weakness of semaphores. A monitor is a shared object with operations, internal state and a number of condition queues. Only one operation of a given monitor may be active at a time i.e. no need to remember to release things –occurs on procedure exit. For example; monitor synch integer i; condition c; procedure producer(x);. end; procedure consumer(x);. end; end monitor; There is only one process that can enter a monitor, therefore every monitor has its own waiting list with process waiting to enter the monitor.

30. Basic disadvantage of semaphore, which is overcome in Monitors The basic disadvantage of semaphore is that it requires busy waiting which wastes CPU cycle that some other process might be able to use productively. Monitors have the property for achieving mutual exclusion i.e. the process only can be active in a monitor at any instant. Consequently the programmer does not need to code the synchronization constraint explicitly.

31. Solution to the Dining Philosophers Problem using Monit ors monitor dining-philosophers { enum state {thinking, hungry, eating}; state state[5]; condition self[5]; void pickup (int i) { state[i] = hungry; test(i); if (state[i] != eating) self[i].wait; } void putdown (int i) { state[i] = thinking; test(i+4 % 5); test(i+1 % 5); } void test (int k) { if ((state[k+4 % 5] != eating) && (state[k]==hungry) && state[k+1 % 5] != eating)) { state[k] = eating; self[k].signal; } init { for (int i = 0; i< 5; i++) state[i] = thinking; }