CS 519: Lecture 2

1. CS 519: Lecture 2 Processes, Threads, and Synchronization

2. Assignment 1 • Design and implement a threads package (details left out on purpose!) • Check the Web page and the newsgroup for further details • Groups of 3 students. Anybody still looking for a group? • Due 2/12/2001 at 5pm Operating System Theory

3. Introduction: Von Neuman Model • Both text (program) and data reside in memory • Execution cycle • Fetch instruction • Decode instruction • Execute instruction • OS is just a program • OS text and data reside in memory too • Invoke OS functionality through procedure calls CPU Memory Operating System Theory

4. Execution Mode • Most processors support at least two modes of execution for protection reasons • Privileged - kernel-mode • Non-privileged - user-mode • The portion of the OS that executes in kernel-mode is called the kernel • Access hardware resources • Protected from interference by user programs • Code running in kernel-mode can do anything - no protection • User code executes in user-mode • OS functionality that does not need direct access to hardware may run in user-mode Operating System Theory

5. Interrupts and traps • Interrupt: an asynchronous event • External events which occur independently of the instruction execution in the processor, e.g. DMA completion • Can be masked (specifically or not) • Trap: a synchronous event • Conditionally or unconditionally caused by the execution of the current instruction, e.g. floating point error, trap instruction • Interrupt and trap events are predefined (typically as integers) • Each interrupt and trap has an associated interrupt vector • Interrupt vector specifies a handler that should be called when the event occurs • Interrupts and traps force the processor to save the current state of execution and jump to the handler Operating System Theory

6. Process • An “instantiation” of a program • System abstraction – the set of resources required for executing a program • Execution context(s) • Address space • File handles, communication endpoints, etc. • Historically, all of the above “lumped” into a single abstraction • More recently, split into several abstractions • Threads, address space, protection domain, etc. • OS process management: • Supports creation of processes and interprocess communication (IPC) • Allocates resources to processes according to specific policies • Interleaves the execution of multiple processes to increase system utilization Operating System Theory

7. Process Image • The physical representation of a process in the OS • A process control structure includes • Identification info: process, parent process, user • Control info: scheduling (state, priority), resources (memory, opened files), IPC • Execution contexts – threads • An address space consisting of code, data, and stack segments Operating System Theory

8. Process Address Space A: … B() … B: … C() … C: OS C Code Globals B Stack A’s activation frame Heap Operating System Theory

9. Virtual Memory • Process addresses are virtual memory addresses • Mapping from virtual memory to physical memory • Details next lecture • Translation: Translation Look-aside Buffer (TLB), page table • Will cover more next time … Operating System Theory

10. User Mode • When running in user-mode, a process can only access its virtual memory and processor resources (registers) directly • All other resources can only be accessed through the kernel by “calling the system” • System call • A system call is a call because it looks like a procedure call • It’s a system call because, in reality, it’s a software trap • Why is a system call a trap instead of a procedure call? Operating System Theory

11. User Mode • When running in user-mode, a process can only access its virtual memory and processor resources (registers) directly • All other resources can only be accessed through the kernel by “calling the system” • System call • A system call is a call because it looks like a procedure call • It’s a system call because, in actuality, it’s a software trap • Why is a system call a trap instead of a procedure call? Need to switch to kernel mode Operating System Theory

12. Mode switching • One or several bits in the processor status word (PSW) indicate the current mode of execution • Sometimes also the previous mode • (Other bits in PSW: interrupt enabled/disabled flags, alignment check bit, arithmetic overflow bit, parity bit, carry bit, etc.) • Mode bits can be changed explicitly while in kernel-mode but not in user-mode • The processor status word can be loaded from the interrupt vector along with the address of the interrupt handler • Setting of kernel mode bit in the interrupt vector allows interrupt and trap handlers to be “automatically” executed in kernel mode Operating System Theory

13. System Call In Monolithic OS interrupt vector for trap instruction PSW PC in-kernel file system(monolithic OS) code for read system call kernel mode trap iret user mode read(....) Operating System Theory

14. Signals • OS may need to “upcall” into user processes • Signals • UNIX mechanism to upcall when an event of interest occurs • Potentially interesting events are predefined: e.g., segmentation violation, message arrival, kill, etc. • When interested in “handling” a particular event (signal), a process indicates its interest to the OS and gives the OS a procedure that should be invoked in the upcall. Operating System Theory

15. Handler B B A A Signals (Cont’d) • When an event of interest occurs the kernel handles the event first, then modifies the process’s stack to look as if the process’s code made a procedure call to the signal handler. • When the user process is scheduled next it executes the handler first • From the handler the user process returns to where it was when the event occurred Operating System Theory

16. Process Creation • How to create a process? System call. • In UNIX, a process can create another process using the fork() system call • int pid = fork() • The creating process is called the parent and the new process is called the child • The child process is created as a copy of the parent process (process image and process control structure) except for the identification and scheduling state • Parent and child processes run in two different address spaces  by default no memory sharing • Process creation is expensive because of this copying Operating System Theory

17. Example of Process Creation Using Fork • The UNIX shell is command-line interpreter whose basic purpose is for user to run applications on a UNIX system • cmd arg1 arg2 ... argn Operating System Theory

18. Inter-Process Communication • Most operating systems provide several abstractions for inter-process communication: message passing, shared memory, etc • Communication requires synchronization between processes (i.e. data must be produced before it is consumed) • Synchronization can be implicit (message passing) or explicit (shared memory) • Explicit synchronization can be provided by the OS (semaphores, monitors, etc) or can be achieved exclusively in user-mode (if processes share memory) Operating System Theory

19. Inter-Process Communication • More on shared memory and message passing later • Synchronization after we talk about threads Operating System Theory

20. Threads • Why limit ourselves to a single execution context? • For example, have to use select() to deal with multiple outstanding events. Having multiple execution contexts is more natural. • Multiprocessor systems • Multiple execution contexts  threads • All the threads of a process share the same address space and the same resources • Each thread contains • An execution state: running, ready, etc.. • An execution context: PC, SP, other registers • A per-thread stack Operating System Theory

21. OS OS Code Code Globals Globals Stack Stack Stack Heap Heap Process Address Space Revisited (a) Single-threaded address space (b) Multi-threaded address space Operating System Theory

22. Threads vs. Processes • Why multiple threads? • Can’t we use multiple processes to do whatever it is that we do with multiple threads? • Sure, but we would need to be able to share memory (and other resources) between multiple processes • This sharing is directly supported by threads – see later in the lecture • Operations on threads (creation, termination, scheduling, etc) are cheaper than the corresponding operations on processes • This is because thread operations do not involve manipulations of other resources associated with processes • Inter-thread communication is supported through shared memory without kernel intervention • Why not? Have multiple other resources, why not execution contexts Operating System Theory

23. Process state diagram ready (in memory) swap in swap out suspended (swapped out) Operating System Theory

24. Thread State Diagram thread scheduling dispatch running ready timeout wait for event event occurred activate suspend suspend suspended blocked (swapped out) process scheduling Operating System Theory

25. Thread Switching • Typically referred to as context switching • Context switching is the act of taking a thread off of the processor and replacing it with another one that is waiting to run • A context switch takes place when • Time quota allocated to the executing thread expires • The executing thread performs a blocking system call • A memory fault due to a page miss Operating System Theory

26. Context Switching • How to do a context switch? • Very carefully!! • Save state of currently executing thread • Copy all “live” registers to thread control block • Need at least 1 scratch register – points to area of memory in thread control block that registers should be saved to • Restore state of thread to run next • Copy values of live registers from thread control block to registers • How to get into and out of the context switching code? Operating System Theory

27. Context Switching • OS is just code stored in memory, so … • Call context switching subroutine • The subroutine saves context of current thread, restores context of the next thread to be executed, and returns • The subroutine returns in the context of another (the next) thread! • Eventually, will switch back to the current thread • To thread, it appears as if the context switching subroutine just took a long while to return Operating System Theory

28. Thread Switching (Cont’d) • What if switching to a thread of a different process? Context switch to process. • Implications for caches, TLB, page table, etc.? • Caches • Physical addresses: no problem • Virtual addresses: cache must either have process tag or must flush cache on context switch • TLB • Each entry must have process tag or flush TLB on context switch • Page table • Typically have page table pointer (register) that must be reloaded on context switch Operating System Theory

29. Process Swapping • May want to swap out entire process • Thrashing if too many processes competing for resources • To swap out a process • Suspend all of its threads • Must keep track of whether thread was blocked or ready • Copy all of its information to backing store (except for PCB) • To swap a process back in • Copy needed information back into memory, e.g. page table, thread control blocks • Restore each thread to blocked or ready • Must check whether event(s) has (have) already occurred Operating System Theory

30. Threads & Signals (Usual Unix Implementation) • A signal is directed to a single thread (we don’t want a signal delivered multiple times), but the handler is associated with the process • Signals can be ignored/masked by threads. Common strategy: one thread responsible to field all signals (calls sigwait() in an infinite loop); all other threads mask all signals • What happens if kernel wants to signal a process when all of its threads are blocked? When there are multiple threads, which thread should the kernel deliver the signal to? • OS writes into PCB that a signal should be delivered to the process • If one thread is responsible for all signals, it is scheduled to run and fields the signal • Otherwise, the next time any thread that does not mask the signal is allowed to run, the signal is delivered to that thread as part of the context switch Operating System Theory

31. POSIX Threads (Pthreads) API Standard • thread creation and termination pthread_create(&tid,NULL,start_fn,arg); pthread_exit(status)’ • thread join pthread_join(tid, &status); • mutual exclusion pthread_mutex_lock(&lock); pthread_mutex_unlock(&lock); • condition variable pthread_cond_wait(&c,&lock); pthread_cond_signal(&c); Operating System Theory

32. Thread Implementation • Kernel-level threads (lightweight processes) • Kernel sees multiple execution contexts • Thread management done by the kernel • User-level threads • Implemented as a thread library which contains the code for thread creation, termination, scheduling and switching • Kernel sees one execution context and is unaware of thread activity • Can be preemptive or not Operating System Theory

33. User-Level vs. Kernel-Level Threads • Advantages of user-level threads • Performance: low-cost thread operations and context switching, since it is not necessary to go into the kernel • Flexibility: scheduling can be application-specific • Portability: user-level thread library easy to port • Disadvantages of user-level threads • If a user-level thread is blocked in the kernel, the entire process (all threads of that process) are blocked • Cannot take advantage of multiprocessing (the kernel assigns one process to only one processor) Operating System Theory

34. User-Level vs. Kernel-Level Threads user-level threads kernel-level threads threads thread scheduling user kernel threads process thread scheduling process scheduling process scheduling processor processor Operating System Theory

35. User-Level vs. Kernel-Level Threads • No reason why we shouldn’t have both (e.g. Solaris) • Most systems now support kernel threads • User-level threads are available as linkable libraries user-level threads thread scheduling user kernel kernel-level threads thread scheduling process scheduling processor Operating System Theory

36. Kernel Support for User-Level Threads • Even kernel threads are not quite the right abstraction for supporting user-level threads • Mismatch between where the scheduling information is available (user) and where scheduling on real processors is performed (kernel) • When the kernel thread is blocked, the corresponding physical processor is lost to all user-level threads although there may be some ready to run. Operating System Theory

37. Why Kernel Threads Are Not The Right Abstraction user-level threads user-level scheduling user kernel kernel thread blocked kernel-level scheduling physical processor Operating System Theory

38. Scheduler Activations • Kernel allocates processors to processes as scheduler activations • Each process contains a user-level thread system which controls the scheduling of the allocated processors • Kernel notifies a process whenever the number of allocated processors changes or when a scheduler activation is blocked due to the user-level thread running on it • The process notifies the kernel when it needs more or fewer scheduler activations (processors) Operating System Theory

39. User-Level Threads On Top ofScheduler Activations user-level threads user-level scheduling user blocked active kernel scheduler activation active blocked kernel-level scheduling physical processor Operating System Theory

40. Thread/Process Operation Latencies VAX uniprocessor running UNIX-like OS, 1992. Operating System Theory

41. Synchronization • Why synchronization? • Problem • Threads share data • Data integrity must be maintained • Example • Transfer $10 from account A to account B A  A + 10 B  B - 10 • If was taking snapshot of account balances, don’t want to read A and B between the previous two statements Operating System Theory

42. Terminology • Critical section: a section of code which reads or writes shared data • Race condition: potential for interleaved execution of a critical section by multiple threads • Results are non-deterministic • Mutual exclusion: synchronization mechanism to avoid race conditions by ensuring exclusive execution of critical sections • Deadlock: permanent blocking of threads • Livelock: execution but no progress • Starvation: one or more threads denied resources Operating System Theory

43. Requirements for Mutual Exclusion • No assumptions on hardware: speed, # of processors • Execution of CS takes a finite time • A thread/process not in CS cannot prevent other threads/processes to enter the CS • Entering CS cannot de delayed indefinitely: no deadlock or starvation Operating System Theory

44. Synchronization Primitives • Most common primitives • Mutual exclusion • Condition variables • Semaphores • Monitors • Need • Semaphores • Mutual exclusion and condition variables Operating System Theory

45. Mutual Exclusion • Mutual exclusion used when want to be only thread modifying a set of data items • Have three components: • Lock, Unlock, Waiting • Example: transferring $10 from A to B Lock(A) Lock(B) A  A + 10 B  B - 10 Unlock(B) Unlock(A) Function Transfer (Amount, A, B) Lock(Transfer_Lock) A  A + 10 B  B - 10 Unlock(Transfer_Lock) Operating System Theory

46. Implementation of Mutual Exclusion • Many read/write algorithms for mutual exclusion • See any OS book • Disadvantages: difficult to get correct and not very general • Simple with a little help from the hardware • Atomic read-modify-write instructions • Test-and-set • Fetch-and-increment • Compare-and-swap Operating System Theory

47. Atomic Read-Modify-Write Instructions • Test-and-set • Read a memory location and, if the value is 0, set it to 1 and return true. Otherwise, return false • Fetch-and-increment • Return the current value of a memory location and increment the value in memory by 1 • Compare-and-swap • Compare the value of a memory location with an old value, and if the same, replace with a new value Operating System Theory

48. Simple Spin Lock • Test-and-set Spin_lock(lock) { while (test-and-set(lock) == 0); } Spin_unlock(lock) { lock = 0; } Operating System Theory

49. Load-Locked, Store-Conditional • Load-Linked, Store-Conditional (LLSC) • Pair of instructions may be easier to implement in hardware • Load-linked (or load-locked) returns the value of a memory location • Store-conditional stores a new value to the same memory location if the value of that location has not been changed since the LL. Returns 0 or 1 to indicate success or failure • If a thread is switched out between an LL and an SC, then the SC automatically fails Operating System Theory

50. What To Do While Waiting? • Spinning • Waiting threads keep testing location until it changes value • Doesn’t work on uniprocessor system • Blocking • OS or RT system deschedules waiting threads • Spinning vs. blocking becomes an issue in multiprocessor systems (with > 1 thread/processor) • What is the main trade-off? Operating System Theory