Post on 19-Jan-2016
CPS110: Threads review and
wrap up
Landon Cox
February 11, 2009
Virtual/physical interfaces
HardwareHardware
OSOS
ApplicationsApplications
Classic synchronization problem
Customer room capacity = 9
Sofa capacity = 4
Standing room
Barbershop Customer () { lock.acquire (); while (numInRoom == 9) roomCV.wait (lock); numInRoom++;
while (numOnSofa == 4) sofaCV.wait (lock); numOnSofa++;
while (numInChair == 3) chairCV.wait (lock); numInChair++; numOnSofa--; sofaCV.signal (lock); customerCV.signal (lock); cutCV.wait (lock); numInChair--; chairCV.signal (lock); numInRoom--; roomCV.signal (lock); lock.release ();}
lock;roomCV;numInRoom=0;sofaCV;numOnSofa=0;chairCV;numInChair=0;customerCV;cutCV;
Enter room
Sit on sofa
Sit in chair
Wake up barberWait for cut to finish
Leave the shop
Barbershop Customer () { lock.acquire (); while (numInRoom == 9) roomCV.wait (lock); numInRoom++;
while (numOnSofa == 4) sofaCV.wait (lock); numOnSofa++;
while (numInChair == 3) chairCV.wait (lock); numInChair++; numOnSofa--; sofaCV.signal (lock); customerCV.signal (lock); cutCV.wait (lock); numInChair--; chairCV.signal (lock); numInRoom--; roomCV.signal (lock); lock.release ();}
Barber () { lock.acquire (); while (1) { while (numInChair == 0) customerCV.wait (lock); cutHair (); cutCV.signal (); } lock.release ();}
Barbershop with semaphores
Customer () { room.down () // enter room sofa.down () // sit on sofa chair.down () // sit on chair sofa.up () customer.up () cut.down () // leave chair chair.up () // leave room room.up ()}
Barber () { while (1) { customer.down() // cut hair cut.up () }}
Semaphore room = 9, sofa = 4, chair = 3, customer = 0, cut = 0;
Is anything weird here?
Course administration
Project 1 Due in 1 weeks Should be done with disk scheduler Should be knee-deep in thread library
Extra office hours Will post/announce tomorrow Most will be over the weekend
Any questions?
Course administration
Looking ahead Wrapping up synchronization today Address spaces up next
Mid-term exam In 12 days (February 23) Rest of lecture: mini-review of
threads
Program with two threads
0
high
code library
data
registers
CPU
R0
Rn
PC
“memory”
x
x
programcommon runtime
stack
address space
SP
y
y stack
runningthread
“on deck” and ready to run
Thread context switch
0
high
code library
data
registers
CPU
R0
Rn
PC
“memory”
x
x
programcommon runtime
stack
address space
SP
y
y stack
1. save registers
2. load registers
switch in
switch out
Portrait of a thread
Thread* tThread* t
machine state
name/status, etc.
“fencepost”“fencepost”
0xdeadbeef
Stack
low
highstack topstack top
unused regionunused region
thread objector
thread control block
thread objector
thread control block
char stack[StackSize]char stack[StackSize]
t = new Thread(name);t->Fork(MyFunc, arg);currentThread->Sleep();currentThread->Yield();
t = new Thread(name);t->Fork(MyFunc, arg);currentThread->Sleep();currentThread->Yield();
/* * Save context of the calling thread (old), restore registers of * the next thread to run (new), and return in context of new. */switch/MIPS (old, new) {
old->stackTop = SP;save RA in old->MachineState[PC];save callee registers in old-
>MachineState
restore callee registers from new->MachineState RA = new->MachineState[PC];
SP = new->stackTop;return (to RA)
}
/* * Save context of the calling thread (old), restore registers of * the next thread to run (new), and return in context of new. */switch/MIPS (old, new) {
old->stackTop = SP;save RA in old->MachineState[PC];save callee registers in old-
>MachineState
restore callee registers from new->MachineState RA = new->MachineState[PC];
SP = new->stackTop;
return (to RA)}
/* * Save context of the calling thread (old), restore registers of * the next thread to run (new), and return in context of new. */switch/MIPS (old, new) {
old->stackTop = SP;save RA in old->MachineState[PC];save callee registers in old-
>MachineState
restore callee registers from new->MachineState RA = new->MachineState[PC];
SP = new->stackTop;
return (to RA)}
Ex: SwitchContext on MIPS
Caller-saved registers (if needed) are already saved on the thread’s stack.
Caller-saved registers (if needed) are already saved on the thread’s stack.
Caller-saved regs restored automatically on return.Caller-saved regs restored automatically on return.
Return to procedure that called switch in new thread.
Return to procedure that called switch in new thread.
Save current stack pointer and caller’s return address in old thread object.
Save current stack pointer and caller’s return address in old thread object.
Switch off of old stack and back to new stack.Switch off of old stack and back to new stack.
Thread States and Transitions
running
readyblocked
Scheduler::Run
“wakeup”
Thread::Sleep(voluntary)
Thread::Yield(voluntary or involuntary)
Threads vs. Processes A process is an abstraction
“Independent executing program” Includes at least one “thread of
control”
Also has a private address space (VAS) Requires OS kernel support To be covered in upcoming
lectures
data
data
Threads vs. Processes Threads may share an address
space Have “context” just like vanilla
processes Exist within some process VAS Processes may be “multithreaded”
Key difference thread context switch vs. process context
switch Project 2: manage process context
switches
data
data
Play analogy
Threads
Address space
What is a process?
Threads
Address spaceAnother performance!
Locks Ensure mutual exclusion in critical
sections. A lock is an object, a data item in memory.
Threads pair calls to Acquire and Release. Acquire before entering a critical section. Release after leaving a critical section. Between Acquire/Release, the lock is held. Acquire doesn’t return until previous holder
releases. Waiting locks can spin (a spinlock) or block (a
mutex).
AA
R
R
Portrait of a Lock in Motion
A
A
R
R
Who can explain this figure?
12
Y
X
A1 A2 R2 R1
A2
A1
R1
R2
Dining philosophers
???
Who can explain this figure?
Kernel-supported threads Most OS kernels have kernel-supported threads.
Thread model and scheduling defined by OS NT, advanced Unix, etc.
Linux: threads are “lightweight processes”
dataNew kernel system calls, e.g.: thread_fork thread_exit thread_block thread_alert etc...
Threads can blockindependently inkernel system calls.
Kernel scheduler (not a library) decides which thread to run next.
Threads must enter the kernelto block: no blocking in user space
User-level threads Can also implement user-level threads in a
library. No special support needed from the kernel (use any
Unix) Thread creation and context switch are fast (no syscall) Defines its own thread model and scheduling policies Kernel only sees a single process
Project 1treadyList
data while(1) { t = get next ready thread; scheduler->Run(t);}
Kernel threads
ThreadThread
User mode
SchedulerScheduler
…
PCSP
ThreadThread
…
PCSP
ThreadThread
…
PCSP
ThreadThread
…
PCSP
Kernel mode
What is “kernel mode?” Mode the OS executes in Heightened privileges Will cover later
User threads
Thread
User mode
Scheduler
…
PCSP
Thread Thread
…
PCSP
Thread
…
PCSP
Sched
…
PCSP
Kernel modeKernel mode
Kernel vs user tradeoffs
Which do you expect to perform better? User-threads should perform better Synchronization functions are just a function call Attractive in low-contention scenarios Don’t want to kernel trap on every lock acquire
What is the danger of user-level threads? If a user thread blocks, entire process blocks May be hard to take advantage of multiple CPUs
Possible solution
Asynchronous process-kernel interactions Process never blocks in kernel Library sleeps thread before entering kernel If IO, etc ready, library handles interrupt Restarts thread with correct syscall results
Still not ideal for multi-core Idea: want to create kernel thread for each core Let user library manage multiple kernel threads
Performance Comparison Comparing user-level threads, kernel threads,
and processes.
Operation FastThreadsTopaz
ThreadsUltrix
Processes
Null fork 34 948 11300
Signal-wait 37 441 1840
Procedure call takes 7 microseconds.
Kernel trap takes 19 microseconds.
Maybe kernel trap is not so significant.
What’s next
We now understand threads Each has it a private stack, registers, TCB
Next, we’ll try to understand processes Address spaces differentiate processes Address spaces are tied to memory, not CPU Can think of as a private namespace