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