Download 2_threads

Operating Systems
Lecture 2: Processes and Threads
Maxim Shevertalov
Jay Kothari
William M. Mongan
Lec 2
Operating Systems
1
Goals
•
•
•
•
Process vs. Kernel Thread vs. User “Green” Threads
Thread Cooperation
Synchronization
Implementing Concurrency
Lec 2
Operating Systems
2
Concurrency
•
Uniprogramming:
– Execute one program at a time
• EX: MS/DOS, Early Mac
– Easier to implement, less to worry about
•
Want to execute many applications at the same time
(Multiprogramming)
– WHY????
Lec 2
Operating Systems
3
Concurrency
•
Uniprogramming:
– Execute one program at a time
• EX: MS/DOS, Early Mac
– Easier to implement, less to worry about
•
Want to execute many applications at the same time
(Multiprogramming)
– Windowing systems do not experience slowdown even if an application
is processing data
• EX: Unix, Linux, Mac OS X, Windows NT/2000/XP
– Harder to implement
– All sorts of “concurrency issues”
Lec 2
Operating Systems
4
Concurrency Issues
• Access to resources
P2
P1
– CPU, Memory, I/O
• OS in charge of
coordination
I/O1
• HOW???
MEM
CPU
I/O2
I/O3
P3
Lec 2
Operating Systems
P4
5
Concurrency Issues
• Access to resources
P1
– CPU, Memory, I/O
• OS in charge of
coordination
I/O1
• Abstract the idea of a
process and make it
seem as though it is
executing on a
uniprogramming OS
MEM
CPU
I/O2
• Now worry about
interlacing these
abstractions
Lec 2
P2
I/O3
P3
Operating Systems
P4
6
Abstracting a Process
•
What is a process?
Lec 2
Operating Systems
7
Abstracting a Process
•
What is a process?
– Execution
– Memory
– Registers
Lec 2
...
Data1
Data0
Instn
...
Inst6
Inst5
Inst4
Inst3
Inst2
Inst1
Inst0
Operating Systems
Execution
1.Fetch at PC
2.Decode
3.Execute
4.Write Results
5.Loop
PC
8
Interlacing Processes
•
Interlace with time
•
Remember:
P0
P1
P0
P2
P1
Time
– Program Counter (PC), Stack pointer, Registers
•
Switching
– Save current state
– Load new state
•
When to switch???
Lec 2
Operating Systems
9
Interlacing Processes
•
Interlace with time
•
Remember:
P0
P1
P0
P2
P1
Time
– Program Counter (PC), Stack pointer, Registers
•
Switching
– Save current state
– Load new state
•
When to switch
– Time, voluntary yield, I/O, other concerns
Lec 2
Operating Systems
10
Protection
•
In the current scheme all processors share:
– I/O devices
– Memory
•
Why is that bad??
Lec 2
Operating Systems
11
Protection
•
In the current scheme all processors share:
– I/O devices
– Memory
•
•
Threads can over-ride each other’s data
Threads can access each other’s instructions
Lec 2
Operating Systems
12
Protection
•
To protect we need to make sure that:
– Protect Memory
• Every process does not have access to all memory
– Protect I/O
• Every process does not have access to all I/O
– Preemptive switching of processes
• Use of a timer
• Processes cannot disable the timer
Lec 2
Operating Systems
13
Translations
•
•
Map virtual address space to
physical address space
P1
On a switch load a new
translation map
Code
Data
Stack
Heap
P2
Code
Data
Stack
Heap
Lec 2
Operating Systems
Data
Stack
Heap
Code
Data
Stack
Heap
Code
OS Code
OS Data
14
Context Switching
•
Context Switching
– Changing processes
•
Context switch overhead sets
minimum switching time
Save State
Idle
Reload State
Idle
Save State
Reload State
Lec 2
Operating Systems
Idle
15
Process State
• new: process is
created
new
terminated
admitted
• ready: process is
waiting to run
exit
interrupt
ready
• running: instructions
are executed
• waiting: process is
waiting for an event
I/O or event
completion
running
scheduler
dispatch
I/O or event
wait
waiting
• terminated: process
has finished execution
Lec 2
Operating Systems
16
Creating a process
•
•
Process state is held in a process control block (PCB)
To make a new process:
–
–
–
–
•
Construct PCB
Set up page tables for address space
Copy data from parent process?
Copy I/O state (file handles, etc)
Is process == program ???
Lec 2
Operating Systems
17
Process Collaboration
•
•
•
Hight Creation/memory Overhead
(Relatively) Hight Context-Switch Overhead
Need communication
– How??
Lec 2
Operating Systems
18
Process Collaboration
•
•
•
Hight Creation/memory Overhead
(Relatively) Hight Context-Switch Overhead
Need communication
– Shared-Memory
– Message Passing
Lec 2
Operating Systems
19
Shared Memory
•
•
•
Communicate by
reading/writing to the
same memory
Low overhead
Complex
synchronization
problems
P1
Code
Data
Stack
Heap
Shared
P2
Code
Data
Stack
Heap
Shared
Lec 2
Operating Systems
Data
Stack
Heap
Code
Data
Stack
Heap
Code
Shared
20
Inter-process Communication
•
•
•
•
•
•
Processes send messages through an IPC facility
Transfer information without shared variables
Works over a network
Harder to implement
Maybe more overhead
Less concurrency problems
– Why??
Lec 2
Operating Systems
21
Kernel Threads
•
•
Sequential execution stream within a process
No protection between threads
– Process still contains a single Address Space
•
Why separate threads from processes
– Threads provide concurrency to a process
– Easy to share data
– Heavyweight Process = Process with one thread
Lec 2
Operating Systems
22
Thread State
• State shared by all threads in process/address space
– Contents of memory (global variables, heap)
– I/O state (file system, network, etc.)
• State private to each thread
– Kept in Thread Control Block (TCB)
– CPU registers (including PC)
– Execution Stack
• Parameters, temporary variables
• return PCs
Lec 2
Operating Systems
23
Thread State
•
Each thread has a Thread Control Block (TCB)
–
–
–
–
•
Execution State
Scheduling info
Accounting info
etc.....
OS keeps track of TCBs in protected memory
Lec 2
Operating Systems
24
Thread Queues
•
When thread is not
running, its TCB is in a
scheduler queue
– Separate queues for each
device/signal/condition
– Each queue can have
different scheduling policy
Ready
Head
Tail
Disc
Head
Tail
TCB
TCB
TCB
NULL
NULL
Ether
Head
Tail
Lec 2
Operating Systems
TCB
25
OS Dispatch Loop
Loop {
RunThread();
ChooseNextThread();
SaveStateOfCPU(curTCB);
LoadStateOfCPU(newTCB);
}
Lec 2
Operating Systems
26
Running a Thread
•
How to run a thread
– Load its state
– Load the environment
– Jump to the PC
•
When does the dispatcher get control?
Lec 2
Operating Systems
27
Running a Thread
•
How to run a thread
– Load its state
– Load the environment
– Jump to the PC
•
When does the dispatcher get control?
– Internal events: thread returns control voluntarily
– External events: thread gets preempted
•
More on how later
Lec 2
Operating Systems
28
Creating a Thread
•
Need information:
– Pass a function pointer to application routine
– Pointer to array of arguments
– Size of the stack to allocate
•
Implementation
– Check all arguments
– Allocated new Stack and TCB
– Initialize TCB and place in ready queue
Lec 2
Operating Systems
29
How to initialize Thread
•
Initialize register fields of TCB
– Stack pointer points at the stack
– PC address => OS routine ThreadRoot()
– Two arg registers initialized to function and arguments
Lec 2
Operating Systems
30
Starting a Thread
• Eventually the
dispatcher will select
this TCB and begin in
ThreadRoot()
ThreadRoot
Threaded
Code
• ThreadRoot
– Do Housekeeping
– Switch to user mode
– Call threaded code
– Finish the thread
run thread
switch
ThreadRoot
• starts at user-level
Lec 2
Operating Systems
31
Thread Finish
•
•
•
Needs to re-enter kernel mode
“Wake up” threads waiting for this thread
Can’t deallocate thread yet
– We are running on its stack
– Instead mark thread as to be destroyed
•
Thread Housekeeping on another thread will deallocate
Lec 2
Operating Systems
32
Join System Call
•
One thread can wait for another to finish
– Calling thread is taken off the run queue and placed on the waiting
queue for the thread it is waiting for
•
Where to store this queue?
Lec 2
Operating Systems
33
Join System Call
•
One thread can wait for another to finish
– Calling thread is taken off the run queue and placed on the waiting
queue for the thread it is waiting for
•
Where to store this queue?
– TCB for the thread to join on
Lec 2
Operating Systems
34
Kernel vs. User-Mode threads
•
Kernel threads
– Native threads supported by the kernel
– Every thread is independent
– One process can have multiple threads
•
Problems with Kernel threads
– Need to cross into kernel mode to schedule
•
Lighter Option: User threads
–
–
–
–
•
User program provides threading and scheduling
Multiple threads per kernel thread
May schedule non-preemptively
Cheap
Downsize to User threads
Lec 2
Operating Systems
35
Kernel vs. User-Mode threads
•
Kernel threads
– Native threads supported by the kernel
– Every thread is independent
– One process can have multiple threads
•
Problems with Kernel threads
– Need to cross into kernel mode to schedule
•
Lighter Option: User threads
–
–
–
–
•
User program provides threading and scheduling
Multiple threads per kernel thread
May schedule non-preemptively
Cheap
Downsize to User threads
– When one thread blocks, all block
– Kernel cannot adjust scheduling
Lec 2
Operating Systems
36
Threading Models
User Threads
K
K
K
K
Kernel Threads
One-to-One
User Threads
K
User Threads
K
K
K
K
Kernel Threads
One-to-Many
Kernel Threads
Many-to-Many
Lec 2
Operating Systems
37
Concurrency
•
What does it mean to run two threads “concurrently”?
Lec 2
Operating Systems
38
Concurrency
•
What does it mean to run two threads “concurrently”?
– Scheduler is free to run threads in any order
– Dispatcher can choose to run threads to completion or in time slices in
various chunks
•
Correct threading means that programs work under all
possibilities
Lec 2
Operating Systems
39
Correctness
• Independent Threads
– No state shared with other threads
– Deterministic => Input state determines results
– Reproducible => Can recreate starting conditions
– Scheduling order doesn’t matter
• Cooperating Threads
– Shared State between threads
– Non-deterministic
– Non-reproducible
• Non-deterministic and Non-reproducible means bugs can
be intermittent
Lec 2
Operating Systems
40
Why allow cooperating
threads?
Lec 2
Operating Systems
41
Why allow cooperating
threads?
•
Shared resource
– One computer, many users
•
Speedup
– Overlap I/O and computation
– Multiprocessor
•
Modularity
– Divide and Conquer
– Makes it easier to extend
Lec 2
Operating Systems
42
Thread Cooperation
•
Voting Example:
1: processVote(id){
2:
c = getCandidate(id);
3:
c++;
4:
storeVote(id, c);
5: }
•
How to speed it up?
– Process more than one request at a time
Lec 2
Operating Systems
43
Problem
1: processVote(id){
2:
c = getCandidate(id);
3:
c++;
4:
storeVote(id, c);
5: }
• Most of the time everything is fine, but a race condition
exists
Lec 2
Operating Systems
44
Problem
1: processVote(id){
2:
c = getCandidate(id);
3:
c++;
4:
storeVote(id, c);
5: }
• Most of the time everything is fine, but a race condition
exists
• If two threads make the call with the same id and a
context switch happens after line 2, but before line 3,
what is the value of the stored c?
Lec 2
Operating Systems
45
Atomic Operations
•
•
•
•
Calls that are guaranteed to run to completion or not at all
On most machines memory references and assignments of
words are atomic
Many instructions are not
Threaded programs must work for all possible interleaving
of context switching
Lec 2
Operating Systems
46
Example: Therac - 25
•
Machine for radiation therapy
– Software control or electron accelerator and and beam/Xray production
– Software control of dosage
•
Software error caused the deaths of several patients
– Race conditions on shared variables
– “They determined that data entry speed during editing was a key factor
in producing the error conditions.”
Lec 2
Operating Systems
47
Definitions
• Synchronization
– Using atomic operations to ensure cooperation
• Mutual Exclusion
– Ensuring that only one thread does a particular thing
at a time
• Critical Section
– Piece of code that only one thread at a time should
execute
• Lock
– Prevents someone from doing something
– Lock before a critical section
– Unlock when leaving
Lec 2
Operating Systems
48
Another Example
1:getMilk(){
2: if(noMilk)
3: buyMilk();
5:}
• Lets try to leave a “note” that we are buying milk
Lec 2
Operating Systems
49
Milk Example
2:if(noMilk){
3: if(noNote){
4: leave Note;
5: buyMilk();
6: remove Note;
7: }
8:}
• What’s wrong now?
Lec 2
Operating Systems
50
Milk Example
2:if(noMilk){
3: if(noNote){
4: leave Note;
5: buyMilk();
6: remove Note;
7: }
8:}
• What’s wrong now?
• What if the first thing we do is leave a “note”
Lec 2
Operating Systems
51
Milk Example
2:leave Note;
3:if(noMilk){
4: if(noNote){
5: buyMilk();
6: }
7:}
8:remove Note;
Lec 2
Operating Systems
52
Milk Example
2:leave Note;
3:if(noMilk){
4: if(noNote){
5: buyMilk();
6: }
7:}
8:remove Note;
• No one is getting Milk
• How about two Notes?
Lec 2
Operating Systems
53
Milk Example
Thread 1
2:leave Note A;
3:if(noMilk){
4: if(noNote B){
5: buyMilk();
6: }
7:}
8:remove Note A;
Thread 2
2:leave Note B;
3:if(noMilk){
4: if(noNote A){
5: buyMilk();
6: }
7:}
8:remove Note B;
• Context Switch may cause each thread to think the other
one is getting Milk (Starvation)
Lec 2
Operating Systems
54
Milk Example
Thread 1
2:leave Note A;
3:while(note
B){}
4:if(noMilk){
5: buyMilk();
6:}
7:remove Note A;
Thread 2
2:leave Note B;
3:if(noNote A){
4: if(noMilk){
5: buyMilk();
6: }
7:}
8:remove Note B;
• This works
• … but what’s unfortunate about this solution?
Lec 2
Operating Systems
55
Solution Discussion
•
Works, but unsatisfactory
– This protects a single piece of “Critical-Section” code
– Only protects for two threads
– Thread 1’s code is different from Thread 2’s
•
Better Solution
– Hardware provide better atomic primitives
– Build higher-level programming abstractions on this
Lec 2
Operating Systems
56
Better Solution
•
Suppose we have an implementation of a Lock
– Lock.acquire(): waits until a lock is free, then grabs it
– Lock.release(): unlocks, wake up anyone waiting
•
Then, the milk problem is simple
lock.acquire();
if(noMilk)
buyMilk();
lock.release();
Lec 2
Operating Systems
57
Implementing Locks
•
Atomic Load/Store
– Get solution similar to our solution to the Milk problem
– Complex and error prone
•
Hardware Lock Instruction
– Each feature makes hardware more complex and slow
•
What about putting a task to sleep?
Lec 2
Operating Systems
58
Lock via interrupt
•
Remember dispatcher gets control when:
– Threads relinquish CPU
– Interrupt causes the dispatcher to take CPU
•
Naive implementation of locks:
– LockAcquire{disable Ints;}
– LockRelease{enable Ints;}
•
Why is this a bad idea?
Lec 2
Operating Systems
59
Better implementation
Acquire(){
disable_int;
if(val == BUSY){
wait thread;
sleep;
}else{
val = BUSY;
}
enable_int;
}
•
Release(){
disable_int;
if(anyone waiting){
get thread;
place on ready;
}else{
val = FREE;
}
enable_int;
}
Maintain a lock variable and impose Mutual Exclusion during
changes to that variable
Lec 2
Operating Systems
60
How to re-enable in sleep
•
•
•
•
Where to re-enable interrupts?
Can’t do it before “wait thread”
Can’t do it after “wait thread”
Can’t do it after “sleep”
Lec 2
Acquire(){
disable_int;
if(val == BUSY){
wait thread;
sleep;
}else{
val = BUSY;
}
enable_int;
}
Operating Systems
61
How to re-enable in sleep
•
In Nachos ints are
disabled when
calling sleep, or
any context switch
– responsibility of the
next thread to reenable
Thread A
Thread B
disable ints
sleep
return
enable ints
return
enable ints
Lec 2
Operating Systems
disable ints
sleep
62
Disabling Interrupts
•
•
•
What about disabling interrupts on multicore?
Never execute a blocking call while interrupts are disabled
Would you implement P() by simply disable interrupts, and
V() by enabling interrupts? Why or why not?
– If not, how might you use interrupts to implement P and V instead?
Atomic Read-Modify-Write Instruction
• Problems with interrupt solution
– Can’t give lock implementation to users
– Doesn’t work well on multiprocessor
• Disabling interrupts on all processors requires
messages and can be time consuming
– Atomic instruction sequences
• Read a value from memory and write a new value
atomically
• Hardware responsible
• Can be used on both uniprocessors and
multiprocessors
Lec 2
Operating Systems
64
Atomic Read-Modify-Write
Instruction
•
test&set(&address): most architectures
– sets M[address] to 1 and returns original value
•
swap (&address, register): x86
– swaps the values of address and registers
•
compare&swap(&address, reg1, reg2): 68000
– If M[address]==reg1 sets M[address]=reg2 and returns success,
otherwise returns failure
Lec 2
Operating Systems
65
Locks with test&set
int val = 0;
Acquire(){
while (test&set(val));
}
Release(){
val = 0;
}
•
Problem: Busy-Waiting
Lec 2
Operating Systems
66
test&set: Solution 1
•
Pro
– Machine can receive interrupts
– User code can use this lock
– Works on a multiprocessor
•
Con
– Very inefficient
– Priority Inversion
• If busy thread has higher priority than then one holding the lock we get no
progress
Lec 2
Operating Systems
67
test&set: Better Solution
int guard = 0;
int val = FREE;
Release(){
Acquire(){
while(test&set(guard));
while(test&set(guard));
if(anyone waiting){
if(val == BUSY){
get thread;
wait thread;
place on ready;
sleep & guard = 0;
}else{
}else{
val = FREE;
val = BUSY;
}
buard = 0;
guard = 0;
}
}
}
•
•
Can minimize busy-waiting: similar to minimizing interrupts
NOTE: Sleep has to reset guard variable
Lec 2
Operating Systems
68
Semaphores
•
Semaphores are a kind of lock
– First defined by Dijkstra in late 60s
– Main synchronization primitive used in original UNIX
•
A non-nagative integer value that supports the following two
operations:
– P(): an atomic operation that waits for the semaphor to become positive
and decrements it by 1
– V(): an atomic operation that increments the semaphore by 1, waking up
waiting P, if any
Lec 2
Operating Systems
69
Using Semaphores
•
Mutual Exclusion (initial value=1)
– Binary semaphore
semaphore.P();
<CRITICAL SECTION>
semaphore.V();
•
Scheduling Constraints (initial value = 0)
– Thread should wait for something
ThreadJoin(){semaphore.P();}
ThreadFinish(){semaphore.V();}
Lec 2
Operating Systems
70
Producer-Consumer
• Problem Definition
– Producer puts things into a shared buffer
– Consumer takes them out
– Limited number of space
– Don’t want them to work in lock step
– Can have multiple producers and consumers
• Example: Coke Machine
– Producer can add coke
– Consumers take it out
Lec 2
Operating Systems
71
Solution with Semaphores
Sempahore fullBuffer
= 0;
Semaphore emptyBuffer = NUM_BUFFERS;
Semaphore mutex
= 1;
Consumer(item){
Producer(item){
fullBuffer.P();
emptyBuffer.P();
mutex.P();
mutex.P();
item = Dequeue();
Enqueue(item);
mutex.V();
mutex.V();
emptyBuffer.V();
fullBuffer.V();
return item;
}
}
•
•
Why do we need the mutex?
Is the order of P’s and V’s important
Lec 2
Operating Systems
72
Monitors and Condition
Variables
• Semaphores are dual purpose and can lead to
more errors
• Cleaner solution is to use:
– Locks for mutual exclusion
– Condition variables for scheduling constraints
• Monitor: A lock and zero or more condition
variables
• Condition variable: make it possible to sleep inside
the critical section by automatically releasing a
lock before sleep
Lec 2
Operating Systems
73
Simple Monitor Example
• Operations on
Condition Variables
– wait(&lock): release
lock and sleep
– Signal(): wake up one
waiter
– Broadcast(): wake up
all waiters
Lec 2
Lock lock;
Condition ready;
Queue queue;
AddToQueue(item){
lock.Acquire();
queue.enqueue(item);
ready.signal();
lock.Release();
}
RemoveFromQueue(item){
lock.Acquire();
while(queue.isEmpty()){
ready.wait(&lock);
}
item = queue.dequeue();
lock.Release()
return item;
}
Operating Systems
74
Simple Monitor Example
• Operations on
Condition Variables
– wait(&lock): release
lock and sleep
– Signal(): wake up one
waiter
– Broadcast(): wake up
all waiters
• Why “while” and not
“if”?
Lec 2
Lock lock;
Condition ready;
Queue queue;
AddToQueue(item){
lock.Acquire();
queue.enqueue(item);
ready.signal();
lock.Release();
}
RemoveFromQueue(item){
lock.Acquire();
while(queue.isEmpty()){
ready.wait(&lock);
}
item = queue.dequeue();
lock.Release()
return item;
}
Operating Systems
75
Why “while” and not “if”
while(queue.isEmpty()){
ready.wait(&lock);
}
•
Depends on the type of scheduling
– Hoare-style
• Sinaler gives lock, CPU to waiter
• Waiter runs immediately
• Waiter gives up lock and processor when it exits the critical section or sleeps
again
– Mesa-style (Most Operating Systems)
• Signaler keeps lock and processor
• Waiter placed on ready queue
• Need to check conditions after wait
Lec 2
Operating Systems
76
Operating System Examples
•
•
Windows XP Threads
Linux Thread
Windows XP Threads
Linux Threads
Windows XP Threads
•
•
Implements the one-to-one mapping, kernel-level
Each thread contains
–
–
–
–
•
•
A thread id
Register set
Separate user and kernel stacks
Private data storage area
The register set, stacks, and private storage area
are known as the context of the threads
The primary data structures of a thread include:
– ETHREAD (executive thread block)
– KTHREAD (kernel thread block)
– TEB (thread environment block)
Linux Threads
•
Linux refers to them as tasks rather than
threads
•
Thread creation is done through clone()
system call
•
clone() allows a child task to share the
address space of the parent task (process)
Summary
•
Looked at:
–
–
–
–
–
Lec 2
processes vs. threads
concurrency issues
synchronization
cooperation
implementation of concurrency abstractions
Operating Systems
82