Threads and Critical Sections Vivek Pai / Kai Li Princeton University

2 Gedankenthreads What happens during fork? We need particular mechanisms, but do we have options about what to do?

3 Mechanics Midterm grading finish 26-30: : : : : : : : : : : 1 Quiz still not graded

4 Thread and Address Space Thread A sequential execution stream within a process (also called lightweight process) Address space All the state needed to run a program Provide illusion that program is running on its own machine (protection) There can be more than one thread per address space

5 Concurrency and Threads I/O devices Overlap I/Os with I/Os and computation (modern OS approach) Human users Doing multiple things to the machine: Web browser Distributed systems Client/server computing: NFS file server Multiprocessors Multiple CPUs sharing the same memory: parallel program

6 Typical Thread API Creation Fork, Join Mutual exclusion Acquire (lock), Release (unlock) Condition variables Wait, Signal, Broadcast Alert Alert, AlertWait, TestAlert

7 User vs. Kernel-Level Threads Question What is the difference between user-level and kernel-level threads? Discussions When a user-level thread is blocked on an I/O event, the whole process is blocked A context switch of kernel-threads is expensive A smart scheduler (two-level) can avoid both drawbacks

8 Thread Control Block Shared information Processor info: parent process, time, etc Memory: segments, page table, and stats, etc I/O and file: comm ports, directories and file descriptors, etc Private state State (ready, running and blocked) Registers Program counter Execution stack

9 Threads Backed By Kernel Threads Each thread has a user stack a private kernel stack Pros concurrent accesses to system services works on a multiprocessor Cons More memory Each thread has a user stack a shared kernel stack with other threads in the same address space Pros less memory Does not work on a multiprocessor Cons serial access to system services

10 “Too Much Milk” Problem Don’t buy too much milk Any person can be distracted at any point Person APerson B Look in fridge: out of milk Leave for Wawa Arrive at Wawa Buy milk Arrive home Look in fridge: out of milk Leave for Wawa Arrive at Wawa Buy milk Arrive home

11 A Possible Solution? Thread can get context switched after checking milk and note, but before buying milk if ( noMilk ) { if (noNote) { leave note; buy milk; remove note; } if ( noMilk ) { if (noNote) { leave note; buy milk; remove note; }

12 Another Possible Solution? Thread A switched out right after leaving a note Thread A leave noteA if (noNoteB) { if (noMilk) { buy milk } remove noteA Thread B leave noteB if (noNoteA) { if (noMilk) { buy milk } remove noteB

13 Yet Another Possible Solution? Safe to buy If the other buys, quit Thread A leave noteA while (noteB) do nothing; if (noMilk) buy milk; remove noteA Thread B leave noteB if (noNoteA) { if (noMilk) { buy milk } remove noteB

14 Remarks The last solution works, but Life is too complicated A’s code is different from B’s Busy waiting is a waste Peterson’s solution is also complex What we want is: Acquire(lock); if (noMilk) buy milk; Release(lock); } Critical section

15 What Is A Good Solution Only one process inside a critical section No assumption about CPU speeds Processes outside of critical section should not block other processes No one waits forever Works for multiprocessors

16 Primitives We want to avoid thinking (repeatedly) So, we want some “contract” that provides certain behavior Low-level behavior encapsulated in “primitives” Application uses primitives to construct more complex behavior

17 The Simplistic Acquire/Release Kernel cannot let users disable interrupts Critical sections can be arbitrarily long Used on uniprocessors, but won’t work on multiprocessors Acquire() { disable interrupts; } Release() { enable interrupts; }

18 Disabling Interrupts Done right, serializes activity People think sequentially – easier to reason Guarantees code executes without interruption Delays handling of external events Used throughout the kernel

19 Using Disabling Interrupts Why do we need to disable interrupts at all? Why do we need to enable interrupts inside the loop in Acquire ? Acquire(lock) { disable interrupts; while (lock != FREE){ enable interrupts; disable interrupts; } lock = BUSY; enable interrupts; } Release(lock) { disable interrupts; lock = FREE; enable interrupts; }

20 Using Disabling Interrupts When does Acquire re-enable interrupts in going to sleep? Before enqueue? After enqueue but before block? Acquire(lock) { disable interrupts; while (lock == BUSY) { enqueue me for lock; block; } else lock = BUSY; enable interrupts; } Release(lock) { disable interrupts; if (anyone in queue) { dequeue a thread; make it ready; } lock = FREE; enable interrupts; }

21 Hardware Support for Mutex Mutex = mutual exclusion Early software-only approaches limited Hardware support became common Various approaches: Disabling interrupts Atomic memory load and store Atomic read-modify-write L. Lamport, “A Fast Mutual Exclusion Algorithm,” ACM Trans. on Computer Systems, 5(1):1-11, Feb – use Google to find

22 The Big Picture Concurrent Applications Locks Semaphores Monitors Send/Receive Load/Store Interrupt disable Test&Set High-Level Atomic API Low-Level Atomic Ops Interrupt (timer or I/O completion), Scheduling, Multiprocessor

23 Atomic Read-Modify-Write Instructions Test&Set: Read value and write 1 back to memory Exchange ( xchg, x86 architecture) Swap register and memory Compare and Exchange ( cmpxchg, 486+) If Dest = ( al,ax,eax ), Dest = SRC; else ( al,ax,eax ) = Dest LOCK prefix in x86 Load link and conditional store (MIPS, Alpha) Read value in one instruction, do some operations When store, check if value has been modified. If not, ok; otherwise, jump back to start

24 A Simple Solution with Test&Set Waste CPU time Low priority threads may never get a chance to run Acquire(lock) { while (!TAS(lock)) ; } Release(lock) { lock = 0; }

25 Test&Set, Minimal Busy Waiting Why does this work? Acquire(lock) { while (!TAS(lock.guard)) ; if (lock.value) { enqueue the thread; block and lock.guard = 0; } else { lock.value = 1; lock.guard = 0; } Release(lock) { while (!TAS(lock.guard)) ; if (anyone in queue) { dequeue a thread; make it ready; } else lock.value = 0; lock.guard = 0; }