CSCE 455/855 Distributed Operating Systems Threads

CSCE 455/855 Distributed Operating Systems

Threads

http://www.cse.unl.edu/~goddard/Courses/CSCE855

1 Steve Goddard Lecture 7 Lecture Steve Goddard CSCE 455/855 Two Types of of Processes Types Two ◆ ◆ “Lightweight” process: Threads “Heavyweight” process maintainstate, own programcounter, » other with is memory shared » normal process that does not share » stack processes processes other with memory thread1 thread 2 thread thread1 Stack Stack Code child parent Data pc pc Code Data Stack Code Stack Data pc pc 2

CSCE 455/855

Steve Goddard 2 Page Lecture 7 Page 1 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