Page 1 Two Types of Processes parent child 1 ◆ “Heavyweight” process pc pc » normal process that does not share Stack Stack memory with other processes Data Data Code Code ◆ “Lightweight” process: Threads thread1 thread 2 pc pc » memory is shared with other Stack Stack processes Data » maintain own state, program counter, Code stack 2 Threads Steve Goddard [email protected] http://www.cse.unl.edu/~goddard/Courses/CSCE855 CSCE 455/855 CSCE Operating Systems Distributed CSCE 455/855 Steve Goddard Lecture 7 Page 2 CSCE 455/855 CSCE Steve Goddard Lecture 7 Threads Example Use of Threads ◆ Characteristics ◆ File servers must block while waiting for disk » thread shares address space with other threads ◆ May want to “multiprogram” the file server ❖ therefore has access to same global variables ❖ can also wipe out other threads’ work (overwrite variables, etc) » while blocked, process next request » also shares open files, signals, semaphores, ports, etc. ◆ Threads a convenient way to do this » threads have ready, blocked. running states » program one file server ❖ scheduled just like processes (1 per CPU) » spawn threads as needed ◆ Threads simply replicate a program » runs the same code » local variables on private stack, just like any other program » but now we have >1 instances of the program ❖ which may be at different places in the program 3 4 CSCE 455/855 CSCE 455/855 Steve Goddard Lecture 7 Page 3 Steve Goddard Lecture 7 Page 4 Advantages of Threads User vs. Kernel Threads ◆ Sharing data is easy ◆ User threads ◆ Kernel threads » kernel schedules processes/tasks » kernel schedules and manages » reduction in interprocess communication overhead » task schedules individual threads threads » just synchronize critical sections in shared data » allows for customized scheduling » when a thread blocks, choose ◆ Less overhead for context switching algorithms another thread ❖ but must be done within the task ❖ kernel can also preempt threads » address space (paging tables for ex.) is the same scheduled by kernel » either from same or different ◆ Ease of programming » problem: how other threads get process/task scheduled » beware of context switch » only one address space to worry about ❖ only if current thread releases ❖ between task switching is CPU (gets blocked) expensive » some systems don’t have kernel ❖ will want to schedule threads from threads same task together ❖ threads packages for UNIX exist 5 6 CSCE 455/855 CSCE 455/855 Steve Goddard Lecture 7 Page 5 Steve Goddard Lecture 7 Page 6 User Threads User Threads (cont.) ◆ Thread package runs on top of kernel ◆ Blocking system calls » referred to as ‘user-space runtime system’ » if a blocking system call goes to the kernel... » kernel maintains processes ❖ the kernel suspends the process » user program maintains threads » want to call another thread when one becomes blocked ❖ package provides procedures for managing threads - the ❖ use non-blocking calls (some OS’s don’t support these) runtime system ❖ Unix select() - use instead of read - if read() would block, call thread manager instead ◆ Advantages ◆ » can run threads on process-oriented systems (like Unix) Page faults » each process can have customized scheduling algorithm » kernel would block entire process on page fault ❖ even though another thread may not be blocked » context switch is minimized » no real solution to this... 7 8 CSCE 455/855 CSCE 455/855 Steve Goddard Lecture 7 Page 7 Steve Goddard Lecture 7 Page 8 User Threads (cont.) Kernel Threads ◆ Preemption of processes ◆ Kernel schedules threads, not processes » no good way to perform preemptive scheduling » when a thread blocks, kernel can schedule: ❖ clock interrupts are at process level ❖ another thread from the same process » thread must voluntarily give up CPU ❖ a thread from a different process » can lead to deadlock » context switch is more expensive ❖ for ex: waiting for a semaphore with a blocking system call ❖ kernel has to maintain process tables with thread entries ◆ User-level problems with page faults, deadlock don’t occur 9 10 CSCE 455/855 CSCE 455/855 Steve Goddard Lecture 7 Page 9 Steve Goddard Lecture 7 Page 10 Threads in Distributed Threads in Distributed Environments Environments ◆ Multiprocessors ◆ Threads for the client/server model » task environment located in shared memory » each client makes a request to the server » threads can run in parallel on different CPUs » server executes identical procedure for all calls » just need to synchronize shared memory access ❖ context switching may dominate server processing! ◆ Networked environments » threads reduce overhead » Can a task on machine X have a thread on machine Y? » make server programming easier ❖ not without the task environment » Why are threads an issue for distributed systems? ❖ because server model needs multiple copies running the same code 11 12 CSCE 455/855 CSCE 455/855 Steve Goddard Lecture 7 Page 11 Steve Goddard Lecture 7 Page 12 Programming with Threads Programming with Threads Critical regions v.s. Resource sharing ◆ Thread management ◆ Mutex ◆ Condition variables » static threads: number of threads is fixed » essentially a binary » use for long term waiting » dynamic threads: threads can be created and destroyed semaphore » using signals on condition variables at run time » in C Threads package: reduces probability of deadlock ❖ can re-use threads ❖ mutex_lock(mutexId) » condition_wait(conditionId, ❖ mutex_unlock(mutexId) mutexId) ◆ No protection between threads » non-blocking mutex: ❖ queue request on conditionId » assumption is that threads are designed to cooperate “trylock” ❖ then mutex is released ❖ but global data is shared » deadlock can occur with » condition_signal(conditionId) ❖ what about race conditions? semaphore locks ❖ if a thread is queued in conditionId, unblock it » dependent on thread scheduling strategy ❖ non-preemptive: thread must explicitly yield CPU ❖ preemptive: race conditions can occur 13 14 CSCE 455/855 CSCE 455/855 Steve Goddard Lecture 7 Page 13 Steve Goddard Lecture 7 Page 14 Programming with Threads User vs. Kernel Threads Handling global data The Trade-off ◆ Problem: global system ◆ Solution: each thread given ◆ variables private global variable User: good performance » but the globals are shared » create_global(“data1”) » no costly transitions from user to kernel space among threads ❖ create local space for the global » errno variable in Unix ❖ other threads calling ◆ Kernel: ease of programming » C uses single buffer for each create_global(“data1”) get a stream separate address space » no non-blocking reads, etc. ❖ multiple threads may write » set_global(“data1”) buffer or update pointer ❖ write to the local data store inconsistently » x = read_global(“data1”) ❖ read the data from local store 15 16 CSCE 455/855 CSCE 455/855 Steve Goddard Lecture 7 Page 15 Steve Goddard Lecture 7 Page 16 RPCs and Threads Scheduler Activations Many are satisfied on same machine ◆ kernel allocates “virtual processors” to process ◆ Use shared memory to pass ◆ Pop-up threads » process can allocate them to threads parameters, results » server threads serve no ◆ The upcall » when started, kernel given purpose when idle » kernel communication with thread run-time system interfaces for both client and » therefore discard the thread server » when server invoked, create » when thread blocks, kernel invoked via blocking system call ❖ kernel creates an argument thread on-the-fly » kernel activates run-time system and passes info stack shared by both ❖ map message memory to new » run-time system can now decide which thread to call » when client calls server... thread ❖ client puts info into stack, ❖ note it is less expensive to ◆ Interrupts traps to kernel create a new thread than to ❖ server reads directly from it restore an existing one... » if process is interested in interrupt, kernel calls interrupt address space ❖ Why? handler in run-time system ❖ results passed in same » otherwise interrupted thread is re-started after kernel handles manner interrupt 17 18 CSCE 455/855 CSCE 455/855 Steve Goddard Lecture 7 Page 17 Steve Goddard Lecture 7 Page 18.