COT 5611 Operating Systems Design Principles Spring 2012

COT 5611 Operating Systems Design Principles Spring 2012 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 5: 00 -6: 00 PM

Lecture 19 – Wednesday March 21, 2012 n Reading assignment: ¨ n Chapter 9 from the on-line text Last time – ¨ ¨ ¨ ¨ All-or-nothing and before-or after atomicity Atomicity and processor management Processes, threads, and address spaces Thread coordination with a bounded buffer – the naïve approach Thread management Address spaces and multi-level memories Kernel structures for the management of multiple cores/processors and threads/processes 3/21/2012 Lecture 19 2

Today n n n n n Locks and before-or-after actions; hardware support for locks YIELD Conditions for thread coordination – Safety, Liveness, Bounded-Wait, Fairness Critical sections – a solution to critical section problem Deadlocks Signals Semaphores Monitors Thread coordination with a bounded buffer. ¨ ¨ ¨ 3/21/2012 WAIT NOTIFY AWAIT ADVANCE SEQUENCE TICKET Lecture 19 3

Locks; Before-or-After actions n Locks shared variables which acts as a flag to coordinate access to a shared data. Manipulated with two primitives ACQUIRE ¨ RELEASE ¨ n n Support implementation of before-or-after actions; only one thread can acquire the lock, the others have to wait. All threads must obey the convention regarding the locks. The two operations ACQUIRE and RELEASE must be atomic. Hardware support for implementation of locks RSM – Read and Set Memory ¨ CMP –Compare and Swap ¨ n RSM (mem) If mem=LOCKED then RSM returns r=LOCKED and sets mem=LOCKED ¨ If mem=UNLOCKED the RSM returns r=LOCKED and sets mem=LOCKED ¨ 3/21/2012 Lecture 19 4

3/21/2012 Lecture 19 5

3/21/2012 Lecture 19 6

Important facts to remember n n n Each thread has a unique Thread. Id Threads save their state on the stack. The stack pointer of a thread is stored in the thread table. To activate a thread the registers of the processor are loaded with information from the thread state. What if no thread is able to run create a dummy thread for each processor called a processor_thread which is scheduled to run when no other thread is available ¨ the processor_thread runs in the thread layer ¨ the SCHEDULER runs in the processor layer ¨ n n We have a processor thread for each processor/core. We can use spin locks only if the two processes (the producer and the consumer) run on different CPUs; we need an active process to release a spin lock…. 3/21/2012 Lecture 19 7

Switching threads with dynamic thread creation n Switching from one user thread to another requires two steps Switch from the thread releasing the processor to the processor thread ¨ Switch from the processor thread to the new thread which is going to have the control of the processor ¨ The last step requires the SCHEDULER to circle through the thread_table until a thready to run is found ¨ n n The boundary between user layer threads and processor layer thread is crossed twice Example: switch from thread 0 to thread 6 using YIELD ¨ ENTER_PROCESSOR_LAYER ¨ EXIT_PROCESSOR_LAYER ¨ 3/21/2012 Lecture 19 8

3/21/2012 Lecture 19 9

The control flow when switching from one thread to another n n n The control flow is not obvious as some of the procedures reload the stack pointer (SP) When a procedure reloads the stack pointer then the place where it transfers control when it executes a return is the procedure whose SP was saved on the stack and was reloaded before the execution of the return. ENTER_PROCESSOR_LAYER Changes the state of the thread calling YIELD from RUNNING to RUNNABLE ¨ Save the state of the procedure calling it , YIELD, on the stack ¨ Loads the processors registers with the state of the processor thread, thus starting the SCHEDULER ¨ n EXIT_PROCESSOR_LAYER ¨ Saves the state of processor thread into the corresponding PROCESSOR_TABLE and loads the state of the thread selected by the SCHEDULER to run (in our example of thread 6) in the processor’s registers ¨ Loads the SP with the values saved by the ENTER_PROCESSOR_LAYER 3/21/2012 Lecture 19 10

3/21/2012 Lecture 19 11

3/21/2012 Lecture 19 12

In ENTER PROCESSOR_LAYER instead of SCHEDULER() should be SP processor_table[processor]. topstack 3/21/2012 Lecture 19 13

3/21/2012 Lecture 19 14

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

In practice…. . n Threads run concurrently Race conditions may occur data in the buffer may be overwritten a lock for the bounded buffer the producer acquires the lock before writing the consumer acquires the lock before reading 3/21/2012 Lecture 19 16

3/21/2012 Lecture 19 17

We have to avoid deadlocks n n If a producer thread cannot write because the buffer is full it has to release the lock to allow the consumer thread to acquire the lock to read, otherwise we have a deadlock. If a consumer thread cannot read because there is no new item in the buffer it has to release the lock to allow the consumer thread to acquire the lock to write, otherwise we have a deadlock. 3/21/2012 Lecture 19 18

3/21/2012 Lecture 19 19

In practice… n We have to ensure atomicity of some operations, e. g. , updating the pointers 3/21/2012 Lecture 19 20

One more pitfall of the previous implementation of bounded buffer n If in and out are long integers (64 or 128 bit) then a load requires two registers, e. , g, R 1 and R 2. int “ 0000 FFFF” L R 1, int /* R 1 0000 L R 2, int+1 /* R 2 FFFF n Race conditions could affect a load or a store of the long integer. 3/21/2012 Lecture 19 21

3/21/2012 Lecture 19 22

In practice threads may run on the same system…. n n We cannot use spinlocks for a thread to wait until an event occurs. That’s why we have spent time on YIELD… 3/21/2012 Lecture 19 23

3/21/2012 Lecture 19 24

3/21/2012 Lecture 19 25