1. CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11:30 - 12:30 AM

2. Last time: Monitors Atomicity Hardware support for atomicity  Today Coordination with a bounded buffer Storage models Types of storage Transactions Next time  Review for the midterm Reading assignments  Chapters 6 and 7 of the textbook Lecture 29 – Wednesday, March 27, 2013 Lecture 292

3. Atomicity All-or-Nothing atomicity  A sequence of steps is an all-or-nothing action if, from the point of view of its invoker, the sequence always either  completes, or  aborts in such a way that it appears that the sequence had never been undertaken in the first place. That is, it backs out. Before-or-After atomicity  actions whose effect from the point of view of their invokers is the same as if the actions occurred either completely before or completely after one another. Lecture 293

4. Thread coordination with a bounded buffer Producer-consumer problem  two threads cooperate – the producer is writing in a buffer and the consumer is reading from the buffer. Basic assumptions:  We have only two threads  Threads proceed concurrently at independent speeds/rates  Bounded buffer – only N buffer cells  Messages are of fixed size and occupy only one buffer cell. Lecture 294

5. 5

6. Implicit assumptions for the correctness of the implementation 1. One sending and one receiving thread. Only one thread updates each shared variable. 2. Sender and receiver threads run on different processors  to allow spin locks 3. in and out are implemented as integers large enough so that they do not overflow (e.g., 64 bit integers) 4. The shared memory used for the buffer provides read/write coherence 5. The memory provides before-or-after atomicity for the shared variables in and out 6. The result of executing a statement becomes visible to all threads in program order. No compiler optimization supported Lecture 296

7. Race condition affecting the pointers; both threads A and B increment the pointer “in” (the pointer where the data is written. Lecture 297

8. 8

9. Solutions to thread coordination problems must satisfy a set of conditions Lecture 299 1.Safety: The required condition will never be violated. 2.Liveness: The system should eventually progress irrespective of contention. 3.Freedom From Starvation: No process should be denied progress for ever. That is, every process should make progress in a finite time. 4.Bounded Wait: Every process is assured of not more than a fixed number of overtakes by other processes in the system before it makes progress. 5.Fairness: dependent on the scheduling algorithm FIFO: No process will ever overtake another process. LRU: The process which received the service least recently gets the service next. For example for the mutual exclusion problem the solution should guarantee that: Safety  the mutual exclusion property is never violated Liveness  a thread will access the shared resource in a finite time Freedom for starvation  a thread will access the shared resource in a finite time Bounded wait  a thread will access the shared resource at least after a fixed number of accesses by other threads.

10. Thread coordination problems Dining philosophers Critical section Lecture 2910

11. Lecture 2911 The structure of Philosopher i: do { wait ( chopstick[i] ); wait ( chopStick[ (i + 1) % 5] ); // eat signal ( chopstick[i] ); signal (chopstick[ (i + 1) % 5] ); // think } while (TRUE);

12. A solution to critical section problem Applies only to two threads T i and T j with i,j ={0,1} which share  integer turn  if turn=i then it is the turn of T i to enter the critical section  boolean flag[2]  if flag[i]= TRUE then T i is ready to enter the critical section To enter the critical section thread T i  sets flag[i]= TRUE  sets turn=j If both threads want to enter then turn will end up with a value of either i or j and the corresponding thread will enter the critical section. T i enters the critical section only if either flag[j]= FALSE or turn=i The solution is correct  Mutual exclusion is guaranteed  The liveliness is ensured  The bounded-waiting is met But this solution may not work as load and store instructions can be interrupted on modern computer architectures Lecture 2912

13. Lecture 2913