Operating Systems Lecture 2 Processes and Threads Maxim

Operating Systems Lecture 2: Processes and Threads Maxim Shevertalov Jay Kothari William M. Mongan Lec 2 Operating Systems 1

Goals • • Process vs. Kernel Thread vs. User “Green” Threads Thread Cooperation Synchronization Implementing Concurrency Lec 2 Operating Systems 2

Concurrency • Uniprogramming: – Execute one program at a time • EX: MS/DOS, Early Mac – Easier to implement, less to worry about • Want to execute many applications at the same time (Multiprogramming) – WHY? ? Lec 2 Operating Systems 3

Concurrency • Uniprogramming: – Execute one program at a time • EX: MS/DOS, Early Mac – Easier to implement, less to worry about • Want to execute many applications at the same time (Multiprogramming) – Windowing systems do not experience slowdown even if an application is processing data • EX: Unix, Linux, Mac OS X, Windows NT/2000/XP – Harder to implement – All sorts of “concurrency issues” Lec 2 Operating Systems 4

Concurrency Issues • Access to resources P 1 – CPU, Memory, I/O • OS in charge of coordination P 2 I/O 1 • HOW? ? ? MEM CPU I/O 2 I/O 3 P 3 Lec 2 Operating Systems P 4 5

Concurrency Issues • Access to resources P 1 – CPU, Memory, I/O • OS in charge of coordination I/O 1 • Abstract the idea of a process and make it seem as though it is executing on a uniprogramming OS • Now worry about interlacing these abstractions Lec 2 P 2 Operating Systems MEM CPU I/O 2 I/O 3 P 4 6

Abstracting a Process • What is a process? Lec 2 Operating Systems 7

Abstracting a Process • What is a process? – Execution – Memory – Registers Lec 2 . . . Data 1 Data 0 Instn. . . Inst 6 Inst 5 Inst 4 Inst 3 Inst 2 Inst 1 Inst 0 Operating Systems Execution 1. Fetch at PC 2. Decode 3. Execute 4. Write Results 5. Loop PC 8

Interlacing Processes • Interlace with time P 0 P 1 P 0 P 2 P 1 Time • Remember: – Program Counter (PC), Stack pointer, Registers • Switching – Save current state – Load new state • When to switch? ? ? Lec 2 Operating Systems 9

Interlacing Processes • Interlace with time • Remember: P 0 P 1 P 0 P 2 P 1 Time – Program Counter (PC), Stack pointer, Registers • Switching – Save current state – Load new state • When to switch – Time, voluntary yield, I/O, other concerns Lec 2 Operating Systems 10

Protection • In the current scheme all processors share: – I/O devices – Memory • Why is that bad? ? Lec 2 Operating Systems 11

Protection • In the current scheme all processors share: – I/O devices – Memory • Threads can over-ride each other’s data • Threads can access each other’s instructions Lec 2 Operating Systems 12

Protection • To protect we need to make sure that: – Protect Memory • Every process does not have access to all memory – Protect I/O • Every process does not have access to all I/O – Preemptive switching of processes • Use of a timer • Processes cannot disable the timer Lec 2 Operating Systems 13

Translations Data Stack Heap Code Data Stack Heap Lec 2 Operating Systems Translation Map P 2 Translation Map • Map virtual address space to physical address space P 1 • On a switch load a new translation map Code Data Stack Heap Code OS Data 14

Context Switching • Context Switching – Changing processes • Context switch overhead sets minimum switching time Save State Idle Reload State Idle Save State Reload State Lec 2 Operating Systems Idle 15

Process State • new: process is created new admitted • ready: process is waiting to run exit interrupt ready • running: instructions are executed • waiting: process is waiting for an event terminated I/O or event completion running scheduler dispatch waiting I/O or event wait • terminated: process has finished execution Lec 2 Operating Systems 16

Creating a process • Process state is held in a process control block (PCB) • To make a new process: – – Construct PCB Set up page tables for address space Copy data from parent process? Copy I/O state (file handles, etc) • Is process == program ? ? ? Lec 2 Operating Systems 17

Process Collaboration • Hight Creation/memory Overhead • (Relatively) Hight Context-Switch Overhead • Need communication – How? ? Lec 2 Operating Systems 18

Process Collaboration • Hight Creation/memory Overhead • (Relatively) Hight Context-Switch Overhead • Need communication – Shared-Memory – Message Passing Lec 2 Operating Systems 19

Shared Memory P 1 Code Data Stack Heap Shared Lec 2 Operating Systems Translation Map P 2 Translation Map • Communicate by reading/writing to the same memory • Low overhead • Complex synchronization problems Data Stack Heap Code Shared 20

Inter-process Communication • • • Processes send messages through an IPC facility Transfer information without shared variables Works over a network Harder to implement Maybe more overhead Less concurrency problems – Why? ? Lec 2 Operating Systems 21

Kernel Threads • Sequential execution stream within a process • No protection between threads – Process still contains a single Address Space • Why separate threads from processes – Threads provide concurrency to a process – Easy to share data – Heavyweight Process = Process with one thread Lec 2 Operating Systems 22

Thread State • State shared by all threads in process/address space – Contents of memory (global variables, heap) – I/O state (file system, network, etc. ) • State private to each thread – Kept in Thread Control Block (TCB) – CPU registers (including PC) – Execution Stack • Parameters, temporary variables • return PCs Lec 2 Operating Systems 23

Thread State • Each thread has a Thread Control Block (TCB) – – Execution State Scheduling info Accounting info etc. . . • OS keeps track of TCBs in protected memory Lec 2 Operating Systems 24

Thread Queues • When thread is not running, its TCB is in a scheduler queue – Separate queues for each device/signal/condition – Each queue can have different scheduling policy Ready Head Tail Disc Head Tail TCB TCB NULL Ether Head Tail Lec 2 Operating Systems TCB 25

OS Dispatch Loop { Run. Thread(); Choose. Next. Thread(); Save. State. Of. CPU(cur. TCB); Load. State. Of. CPU(new. TCB); } Lec 2 Operating Systems 26

Running a Thread • How to run a thread – Load its state – Load the environment – Jump to the PC • When does the dispatcher get control? Lec 2 Operating Systems 27

Running a Thread • How to run a thread – Load its state – Load the environment – Jump to the PC • When does the dispatcher get control? – Internal events: thread returns control voluntarily – External events: thread gets preempted • More on how later Lec 2 Operating Systems 28

Creating a Thread • Need information: – Pass a function pointer to application routine – Pointer to array of arguments – Size of the stack to allocate • Implementation – Check all arguments – Allocated new Stack and TCB – Initialize TCB and place in ready queue Lec 2 Operating Systems 29

How to initialize Thread • Initialize register fields of TCB – Stack pointer points at the stack – PC address => OS routine Thread. Root() – Two arg registers initialized to function and arguments Lec 2 Operating Systems 30

Starting a Thread • Eventually the dispatcher will select this TCB and begin in Thread. Root() • Thread. Root Threaded Code – Do Housekeeping – Switch to user mode – Call threaded code – Finish the thread run thread switch Thread. Root • starts at user-level Lec 2 Operating Systems 31

Thread Finish • Needs to re-enter kernel mode • “Wake up” threads waiting for this thread • Can’t deallocate thread yet – We are running on its stack – Instead mark thread as to be destroyed • Thread Housekeeping on another thread will deallocate Lec 2 Operating Systems 32

Join System Call • One thread can wait for another to finish – Calling thread is taken off the run queue and placed on the waiting queue for the thread it is waiting for • Where to store this queue? Lec 2 Operating Systems 33

Join System Call • One thread can wait for another to finish – Calling thread is taken off the run queue and placed on the waiting queue for the thread it is waiting for • Where to store this queue? – TCB for the thread to join on Lec 2 Operating Systems 34

Kernel vs. User-Mode threads • Kernel threads – Native threads supported by the kernel – Every thread is independent – One process can have multiple threads • Problems with Kernel threads – Need to cross into kernel mode to schedule • Lighter Option: User threads – – User program provides threading and scheduling Multiple threads per kernel thread May schedule non-preemptively Cheap • Downsize to User threads Lec 2 Operating Systems 35

Kernel vs. User-Mode threads • Kernel threads – Native threads supported by the kernel – Every thread is independent – One process can have multiple threads • Problems with Kernel threads – Need to cross into kernel mode to schedule • Lighter Option: User threads – – User program provides threading and scheduling Multiple threads per kernel thread May schedule non-preemptively Cheap • Downsize to User threads – When one thread blocks, all block – Kernel cannot adjust scheduling Lec 2 Operating Systems 36

Threading Models User Threads K K Kernel Threads One-to-One User Threads K K Kernel Threads One-to-Many Kernel Threads Many-to-Many Lec 2 Operating Systems 37

Concurrency • What does it mean to run two threads “concurrently”? Lec 2 Operating Systems 38

Concurrency • What does it mean to run two threads “concurrently”? – Scheduler is free to run threads in any order – Dispatcher can choose to run threads to completion or in time slices in various chunks • Correct threading means that programs work under all possibilities Lec 2 Operating Systems 39

Correctness • Independent Threads – No state shared with other threads – Deterministic => Input state determines results – Reproducible => Can recreate starting conditions – Scheduling order doesn’t matter • Cooperating Threads – Shared State between threads – Non-deterministic – Non-reproducible • Non-deterministic and Non-reproducible means bugs can be intermittent Lec 2 Operating Systems 40

Why allow cooperating threads? Lec 2 Operating Systems 41

Why allow cooperating threads? • Shared resource – One computer, many users • Speedup – Overlap I/O and computation – Multiprocessor • Modularity – Divide and Conquer – Makes it easier to extend Lec 2 Operating Systems 42

Thread Cooperation • Voting Example: 1: process. Vote(id){ 2: c = get. Candidate(id); 3: c++; 4: store. Vote(id, c); 5: } • How to speed it up? – Process more than one request at a time Lec 2 Operating Systems 43

Problem 1: process. Vote(id){ 2: c = get. Candidate(id); 3: c++; 4: store. Vote(id, c); 5: } • Most of the time everything is fine, but a race condition exists Lec 2 Operating Systems 44

Problem 1: process. Vote(id){ 2: c = get. Candidate(id); 3: c++; 4: store. Vote(id, c); 5: } • Most of the time everything is fine, but a race condition exists • If two threads make the call with the same id and a context switch happens after line 2, but before line 3, what is the value of the stored c? Lec 2 Operating Systems 45

Atomic Operations • Calls that are guaranteed to run to completion or not at all • On most machines memory references and assignments of words are atomic • Many instructions are not • Threaded programs must work for all possible interleaving of context switching Lec 2 Operating Systems 46

Example: Therac - 25 • Machine for radiation therapy – Software control or electron accelerator and beam/Xray production – Software control of dosage • Software error caused the deaths of several patients – Race conditions on shared variables – “They determined that data entry speed during editing was a key factor in producing the error conditions. ” Lec 2 Operating Systems 47

Definitions • Synchronization – Using atomic operations to ensure cooperation • Mutual Exclusion – Ensuring that only one thread does a particular thing at a time • Critical Section – Piece of code that only one thread at a time should execute • Lock – Prevents someone from doing something – Lock before a critical section – Unlock when leaving Lec 2 Operating Systems 48

Another Example 1: get. Milk(){ 2: if(no. Milk) 3: buy. Milk(); 5: } • Lets try to leave a “note” that we are buying milk Lec 2 Operating Systems 49

Milk Example 2: if(no. Milk){ 3: if(no. Note){ 4: leave Note; 5: buy. Milk(); 6: remove Note; 7: } 8: } • What’s wrong now? Lec 2 Operating Systems 50

Milk Example 2: if(no. Milk){ 3: if(no. Note){ 4: leave Note; 5: buy. Milk(); 6: remove Note; 7: } 8: } • What’s wrong now? • What if the first thing we do is leave a “note” Lec 2 Operating Systems 51

Milk Example 2: leave Note; 3: if(no. Milk){ 4: if(no. Note){ 5: buy. Milk(); 6: } 7: } 8: remove Note; Lec 2 Operating Systems 52

Milk Example 2: leave Note; 3: if(no. Milk){ 4: if(no. Note){ 5: buy. Milk(); 6: } 7: } 8: remove Note; • No one is getting Milk • How about two Notes? Lec 2 Operating Systems 53

Milk Example Thread 1 2: leave Note A; 3: if(no. Milk){ 4: if(no. Note B){ 5: buy. Milk(); 6: } 7: } 8: remove Note A; Thread 2 2: leave Note B; 3: if(no. Milk){ 4: if(no. Note A){ 5: buy. Milk(); 6: } 7: } 8: remove Note B; • Context Switch may cause each thread to think the other one is getting Milk (Starvation) Lec 2 Operating Systems 54

Milk Example Thread 1 2: leave Note A; 3: while(note B){} 4: if(no. Milk){ 5: buy. Milk(); 6: } 7: remove Note A; Thread 2 2: leave Note B; 3: if(no. Note A){ 4: if(no. Milk){ 5: buy. Milk(); 6: } 7: } 8: remove Note B; • This works • … but what’s unfortunate about this solution? Lec 2 Operating Systems 55

Solution Discussion • Works, but unsatisfactory – This protects a single piece of “Critical-Section” code – Only protects for two threads – Thread 1’s code is different from Thread 2’s • Better Solution – Hardware provide better atomic primitives – Build higher-level programming abstractions on this Lec 2 Operating Systems 56

Better Solution • Suppose we have an implementation of a Lock – Lock. acquire(): waits until a lock is free, then grabs it – Lock. release(): unlocks, wake up anyone waiting • Then, the milk problem is simple lock. acquire(); if(no. Milk) buy. Milk(); lock. release(); Lec 2 Operating Systems 57

Implementing Locks • Atomic Load/Store – Get solution similar to our solution to the Milk problem – Complex and error prone • Hardware Lock Instruction – Each feature makes hardware more complex and slow • What about putting a task to sleep? Lec 2 Operating Systems 58

Lock via interrupt • Remember dispatcher gets control when: – Threads relinquish CPU – Interrupt causes the dispatcher to take CPU • Naive implementation of locks: – Lock. Acquire{disable Ints; } – Lock. Release{enable Ints; } • Why is this a bad idea? Lec 2 Operating Systems 59

Better implementation Acquire(){ disable_int; if(val == BUSY){ wait thread; sleep; }else{ val = BUSY; } enable_int; } Release(){ disable_int; if(anyone waiting){ get thread; place on ready; }else{ val = FREE; } enable_int; } • Maintain a lock variable and impose Mutual Exclusion during changes to that variable Lec 2 Operating Systems 60

How to re-enable in sleep • • Where to re-enable interrupts? Can’t do it before “wait thread” Can’t do it after “sleep” Lec 2 Operating Systems Acquire(){ disable_int; if(val == BUSY){ wait thread; sleep; }else{ val = BUSY; } enable_int; } 61

How to re-enable in sleep • In Nachos ints are disabled when calling sleep, or any context switch – responsibility of the next thread to reenable Thread A Thread B disable ints sleep return enable ints Lec 2 Operating Systems conte xt switc h xt e t n co ch swit disable ints sleep 62

Disabling Interrupts • What about disabling interrupts on multicore? • Never execute a blocking call while interrupts are disabled • Would you implement P() by simply disable interrupts, and V() by enabling interrupts? Why or why not? – If not, how might you use interrupts to implement P and V instead?

Atomic Read-Modify-Write Instruction • Problems with interrupt solution – Can’t give lock implementation to users – Doesn’t work well on multiprocessor • Disabling interrupts on all processors requires messages and can be time consuming – Atomic instruction sequences • Read a value from memory and write a new value atomically • Hardware responsible • Can be used on both uniprocessors and multiprocessors Lec 2 Operating Systems 64

Atomic Read-Modify-Write Instruction • test&set(&address): most architectures – sets M[address] to 1 and returns original value • swap (&address, register): x 86 – swaps the values of address and registers • compare&swap(&address, reg 1, reg 2): 68000 – If M[address]==reg 1 sets M[address]=reg 2 and returns success, otherwise returns failure Lec 2 Operating Systems 65

Locks with test&set int val = 0; Acquire(){ while (test&set(val)); } Release(){ val = 0; } • Problem: Busy-Waiting Lec 2 Operating Systems 66

test&set: Solution 1 • Pro – Machine can receive interrupts – User code can use this lock – Works on a multiprocessor • Con – Very inefficient – Priority Inversion • If busy thread has higher priority than then one holding the lock we get no progress Lec 2 Operating Systems 67

test&set: Better Solution int guard = 0; int val = FREE; Release(){ Acquire(){ while(test&set(guard)); if(anyone waiting){ if(val == BUSY){ get thread; wait thread; place on ready; sleep & guard = 0; }else{ val = FREE; val = BUSY; } buard = 0; guard = 0; } } } • Can minimize busy-waiting: similar to minimizing interrupts • NOTE: Sleep has to reset guard variable Lec 2 Operating Systems 68

Semaphores • Semaphores are a kind of lock – First defined by Dijkstra in late 60 s – Main synchronization primitive used in original UNIX • A non-nagative integer value that supports the following two operations: – P(): an atomic operation that waits for the semaphor to become positive and decrements it by 1 – V(): an atomic operation that increments the semaphore by 1, waking up waiting P, if any Lec 2 Operating Systems 69

Using Semaphores • Mutual Exclusion (initial value=1) – Binary semaphore. P(); <CRITICAL SECTION> semaphore. V(); • Scheduling Constraints (initial value = 0) – Thread should wait for something Thread. Join(){semaphore. P(); } Thread. Finish(){semaphore. V(); } Lec 2 Operating Systems 70

Producer-Consumer • Problem Definition – Producer puts things into a shared buffer – Consumer takes them out – Limited number of space – Don’t want them to work in lock step – Can have multiple producers and consumers • Example: Coke Machine – Producer can add coke – Consumers take it out Lec 2 Operating Systems 71

Solution with Semaphores Sempahore full. Buffer = 0; Semaphore empty. Buffer = NUM_BUFFERS; Semaphore mutex = 1; Consumer(item){ Producer(item){ full. Buffer. P(); empty. Buffer. P(); mutex. P(); item = Dequeue(); Enqueue(item); mutex. V(); empty. Buffer. V(); full. Buffer. V(); return item; } } • Why do we need the mutex? • Is the order of P’s and V’s important Lec 2 Operating Systems 72

Monitors and Condition Variables • Semaphores are dual purpose and can lead to more errors • Cleaner solution is to use: – Locks for mutual exclusion – Condition variables for scheduling constraints • Monitor: A lock and zero or more condition variables • Condition variable: make it possible to sleep inside the critical section by automatically releasing a lock before sleep Lec 2 Operating Systems 73

Simple Monitor Example • Operations on Condition Variables – wait(&lock): release lock and sleep – Signal(): wake up one waiter – Broadcast(): wake up all waiters Lec 2 Operating Systems Lock lock; Condition ready; Queue queue; Add. To. Queue(item){ lock. Acquire(); queue. enqueue(item); ready. signal(); lock. Release(); } Remove. From. Queue(item){ lock. Acquire(); while(queue. is. Empty()){ ready. wait(&lock); } item = queue. dequeue(); lock. Release() return item; } 74

Simple Monitor Example • Operations on Condition Variables – wait(&lock): release lock and sleep – Signal(): wake up one waiter – Broadcast(): wake up all waiters • Why “while” and not “if”? Lec 2 Operating Systems Lock lock; Condition ready; Queue queue; Add. To. Queue(item){ lock. Acquire(); queue. enqueue(item); ready. signal(); lock. Release(); } Remove. From. Queue(item){ lock. Acquire(); while(queue. is. Empty()){ ready. wait(&lock); } item = queue. dequeue(); lock. Release() return item; } 75

Why “while” and not “if” while(queue. is. Empty()){ ready. wait(&lock); } • Depends on the type of scheduling – Hoare-style • Sinaler gives lock, CPU to waiter • Waiter runs immediately • Waiter gives up lock and processor when it exits the critical section or sleeps again – Mesa-style (Most Operating Systems) • Signaler keeps lock and processor • Waiter placed on ready queue • Need to check conditions after wait Lec 2 Operating Systems 76

Operating System Examples • Windows XP Threads • Linux Thread

Windows XP Threads

Linux Threads

Windows XP Threads • Implements the one-to-one mapping, kernel-level • Each thread contains – – A thread id Register set Separate user and kernel stacks Private data storage area • The register set, stacks, and private storage area are known as the context of the threads • The primary data structures of a thread include: – ETHREAD (executive thread block) – KTHREAD (kernel thread block) – TEB (thread environment block)

Linux Threads • Linux refers to them as tasks rather than threads • Thread creation is done through clone() system call • clone() allows a child task to share the address space of the parent task (process)

Summary • Looked at: – – – Lec 2 processes vs. threads concurrency issues synchronization cooperation implementation of concurrency abstractions Operating Systems 82