1
50
Processes and Threads
Chapter 2
2.1 Processes2.2 Threads2.3 Interprocess communication2.4 Classical IPC problems2.5 Scheduling
51
ProcessesThe Process Model
• Multiprogramming of four programs• Conceptual model of 4 independent, sequential processes• Only one program active at any instant
2
52
Processes and Multiprogramming
• Sequential process: Multiprogramming fiction
• CPU switched between processes– within process: user and system code
– across processes
• concurrent execution, by nature unpredictable– combination of factors yield specific interleaving
– cannot reproduce, consider nondeterministic
53
NondeterminismDijkstra’s Guarded Commands construct:begin booleanGuard0: statement0; booleanGuard1: statement1;... booleanGuardN: statementN;end
where at most one of the statements gets executed,nondeterministically chosen amongst those whoseboolean guard evaluated to true (all evaluated atthe beginning. (If all guards are false, it’s a no-op)
3
54
Nondeterminism
• Typical scenario: n processes ready to go– cannot assume that P1 executes, then P2, etc.
– n=5: P2, P1, P4, P2, P5, P1, P4, P1, P3
• Design/Correctness cannot rely on order– neither can debugging!
– Heisenbugs (Bruce Lindsay)
• Best hope: “liveness” - “fairness”– of course “safety” taken care of elsewhere
55
Process Essentials
• Processes are sequential in principle
• are created, run, and terminated– they may last almost “forever”, most don’t
• may run on behalf of a user, or to dohousekeeping (“background”)
• may be arranged in a hierarchy or group– child processes, kill all this family, etc.
• may be running, ready, blocked– managed by OS Scheduler
4
56
Process Creation
Events that cause process creation
• System initialization
• Execution of a process creationsystem
• User request to create a new process
• Initiation of a batch job
57
Process Termination
Conditions which terminate processes
1. Normal exit (voluntary)
2. Error exit (voluntary)
3. Fatal error (involuntary)
4. Killed by another process (involuntary)
Scheduler keeps track of processes
5
58
Process Hierarchies
• Parent creates a child process, child processescan create its own process
• Forms a hierarchy– UNIX calls this a "process group”
– can refer to the whole group
• Windows has no concept of process hierarchy– all processes are created equal
59
Process States (1)
• Possible process states– running
– blocked
– ready
• Transitions between states shown
6
60
Process States (2)
• Lowest layer of process-structured OS– handles interrupts, scheduling
• Above that layer are sequential processes
• Abstraction, Policies, Mechanisms?
61
Implementing Processes• Recall HW has NO semantic context
• Process needs a software realization
• What is a process => How do we support it?
Algorithms: OS Code Modules– e.g., Scheduler: priority queue management
+Data Structures: Process tables, per-process
– e.g., PCB process control block, interruptvector
7
62
Implementation of Processes (1)
Fields of a process table entry
63
Implementation of Processes (2)
Skeleton of what lowest level OS does when aninterrupt occurs
8
64
Processes v. Threads
• Process is heavy (see previous slides)– address space (program text & data)
– open files, child processes, alarms, acctg…
– (scheduled) execution thread: program counter,registers, stack
• Separate thread aka lightweight process
65
ThreadsThe Thread Model (1)
(a) Three processes each with one thread(b) One process with three threads
9
66
The Thread Model (2)
• Items shared by all threads in a process
• Items private to each thread
67
The Thread Model (3)
Each thread has its own stack
10
68
Thread Usage (1)
A word processor with three threads
69
Thread Usage (2)
A multithreaded Web server
11
70
Thread Usage (3)
• Rough outline of code for previous slide(a) Dispatcher thread(b) Worker thread
71
Thread Usage (4)
Three ways to construct a server
12
72
Why Threads?
• Same argument as processes: decompose!– some tasks inherently multithreaded, but need
need to share “address space” (resources)
– e.g., word processor: interaction, batch modif
• Threads cheaper to create & destroy– e.g., web server: dispatcher, worker threads
• Multiprogramming - higher concurrency– when mix of CPU and I/O
• Natural abstraction for Multiprocessors
73
Implementing Threads in User Space
A user-level threads package
13
74
Threads in user space
Process keeps its own thread table, schedules
• No OS context switching for concurrency
• Program does its own scheduling– and with no context switch, it’s fast
• But, no preemption, so better get it right
• Nonblocking calls, etc. (see text)
75
Implementing Threads in the Kernel
A threads package managed by the kernel
14
76
Hybrid Implementations
Multiplexing user-level threads onto kernel-level threads
77
Kernel and Hybrid Threads
• Kernel has more control (e.g., preemption),but manipulation is costlier– data in kernel space, context switches
– reuse threads
• Hybrid: kernel threads multiplexed in userspace
• Scheduler activations
15
78
Scheduler Activations
• Goal – mimic functionality of kernel threads– gain performance of user space threads
• Avoids unnecessary user/kernel transitions• Kernel assigns virtual processors to each process
– lets runtime system allocate threads to processors
• Problem: Fundamental reliance on kernel (lower layer)
calling procedures in user space (higher layer)
79
Pop-Up Threads
• Creation of a new thread when message arrives(a) before message arrives(b) after message arrives
Note thread is sort of stateless
16
80
Making Single-Threaded Code Multithreaded (1)
Conflicts between threads over the use of a global variable
81
Making Single-Threaded Code Multithreaded (2)
Threads can have private global variables