Upload
regina-rice
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
CS 162Discussion Section
Week 2(9/16 – 9/20)
Who am I?
Kevin [email protected]://www.cs.berkeley.edu/~klueska
Office Hours: 12:30pm-2:30pm Mondays @ Soda 7th Floor Alcove
Today’s Section
• Talk about the Course Projects (15 min)• Overall Goals, Grading, Version Control• Project 1 Details
• Review Lectures 3 and 4 (10 min)• Worksheet and Discussion (20 min)
Project Goals
• Learn to work in teams • Use good engineering practices• Version control, collaboration• Requirements specification• Design Document• Implementation • Testing• [Performance, reliability, ...] analysis
• Understand lecture concepts at the implementation level
Project Grading
• Design docs [40 points]• First draft [10 points]• Design review [10 points]• Final design doc [20 points]
• Code [60 points]
Good Project Lifetime• Day 0: Project released on course webpage • Day 1 13: Team meets, discusses and breaks up work ‐
on design and necessary prototyping • Day 14: Initial design document due
– Team reviews the document with TA • Day 15: Implementation begins • Day 20: Implementation is finished. Team switches to
writing test cases. Design doc has been updated to reflect the implementation.
• Day 21: Iteration and performance analysis. • Day 23: Team puts finishing touches on write up and
gets to bed early.
Design Documents
• Overview of the project as a whole along with each of its subparts
• Header must contain the following info• Project Name and #• Group Members Names and IDs• Section #• TA Name
• Example docs on the course webpage under: Projects and Nachos-> General Project Information
Design Document Structure
Each part of the project should be explained using the following structure• Overview• Correctness Constraints• Declarations• Descriptions• Testing Plan
Design Doc Length
• Keep under 15 pages• Will dock points if too long!
Design Reviews
• Design reviews• Schedule a time (outside of Section) with your
Section TA to meet and discuss your design• Every member must attend• Will test that every member understands
• YOU are responsible for testing your code• We provide access to a simple autograder• But your project is graded against a much more
extensive autograder
Project 1: Thread Programming
• Can be found in the course website• Under the heading “Projects and Nachos”
• Stock Nachos has an incomplete thread system. Your job is to• Complete it, and • Use it to solve several synchronization problems
Version Control for the Projects
• Course provided SVN and Private GitHub repos for every group
• Use whichever you prefer
• Access:svn: https://isvn.eecs.berkeley.edu/cs162/groupXXgit: https://github.com/Berkeley-CS162/groupXX
Project Questions?
Quiz• (True/False) Each thread owns its own stack and heap.• (True/False) Hardware provides better (higher-level)
primitives than atomic load and store for constructing synchronization tools• (True/False) Correct threaded programs don't need to
work for all interleavings of thread instruction sequences.• (True/False) Timer interrupts are an example of non-
preemptive multithreading• (Short Answer) What is an operation that either runs
to completion or not at all called?
Lecture Review
Putting it together: Processes
…
Process 1
Process 2
Process N
CPU sched
.OS
CPU(1
core)
1 process at a time
CPUstat
e
IOstat
e
Mem.
CPUstat
e
IOstat
e
Mem.
CPUstat
e
IOstat
e
Mem.
• Switch overhead: high• CPU state: low• Memory/IO state: high
• Process creation: high• Protection• CPU: yes• Memory/IO: yes
• Sharing overhead: high (involves at least a context switch)
Putting it together: ThreadsProcess 1
CPU sched
.OS
CPU(1
core)
1 thread at a time
IOstat
e
Mem.
…
threads
Process N
IOstat
e
Mem.
…
threads
…
• Switch overhead: low (only CPU state)
• Thread creation: low• Protection• CPU: yes• Memory/IO: No
• Sharing overhead: low (thread switch overhead low)
CPUstate
CPUstate
CPUstate
CPUstate
Why Processes & Threads?• Multiprogramming: Run multiple applications
concurrently• Protection: Don’t want a bad application to crash
system!
Goals:
Process: unit of execution and allocation• Virtual Machine abstraction: give process illusion it
owns machine (i.e., CPU, Memory, and IO device multiplexing)
Solution:
• Process creation & switching expensive• Need concurrency within same app (e.g., web
server)
Challenge:
Thread: Decouple allocation and execution• Run multiple threads within same process
Solution:
Dispatch Loop
• Conceptually, the dispatching loop of the operating system looks as follows:
Loop { RunThread(); ChooseNextThread(); SaveStateOfCPU(curTCB); LoadStateOfCPU(newTCB);}
• This is an infinite loop• One could argue that this is all that the OS does
Yielding through Internal Events
• Blocking on I/O• The act of requesting I/O implicitly yields the
CPU• Waiting on a “signal” from other thread• Thread asks to wait and thus yields the CPU
• Thread executes a yield()• Thread volunteers to give up CPU
computePI() { while(TRUE) { ComputeNextDigit(); yield(); } }• Note that yield() must be called by
programmer frequently enough!
Review: Two Thread Yield Example
• Consider the following code blocks: proc A() {
B();
}proc B() { while(TRUE) {
yield(); }
}
• Suppose we have two threads:• Threads S and T
Thread S
A
B(while)
yield
run_new_threadswitch
kernel_yield
Thread T
A
B(while)
yield
run_new_threadswitch
kernel_yield
Why allow cooperating threads?• People cooperate; computers help/enhance people’s
lives, so computers must cooperate• By analogy, the non-reproducibility/non-determinism of
people is a notable problem for “carefully laid plans”
• Advantage 1: Share resources• One computer, many users
• One bank balance, many ATMs• What if ATMs were only updated at night?
• Embedded systems (robot control: coordinate arm & hand)
• Advantage 2: Speedup• Overlap I/O and computation
• Multiprocessors – chop up program into parallel pieces
• Advantage 3: Modularity • Chop large problem up into simpler pieces
• To compile, for instance, gcc calls cpp | cc1 | cc2 | as | ld
• Makes system easier to extend
Definitions• Synchronization: using atomic operations
to ensure cooperation between threads• For now, only loads and stores are atomic• We’ll show that is hard to build anything
useful with only reads and writes
• Critical Section: piece of code that only one thread can execute at once
• Mutual Exclusion: ensuring that only one thread executes critical section• One thread excludes the other while doing
its task• Critical section and mutual exclusion are two
ways of describing the same thing
Better Implementation of Locks by Disabling Interrupts
• Key idea: maintain a lock variable and impose mutual exclusion only during operations on that variableint value = FREE;
Acquire() {disable interrupts;if (value == BUSY) {
put thread on wait queue;Go to sleep();// Enable
interrupts?} else {
value = BUSY;}enable interrupts;
}
Release() {disable interrupts;
if (anyone on wait queue) {take thread off
wait queue;Put at front of
ready queue;} else {
value = FREE;}
enable interrupts;}
How to Re-enable After Sleep()?
• Since ints are disabled when you call sleep:• Responsibility of the next thread to re-enable
ints• When the sleeping thread wakes up, returns
to acquire and re-enables interruptsThread A Thread B . .disable intssleep
. .
sleep returnenable ints . .
contextswitch
conte
xtswitch
yield returnenable ints
disable intyield
Worksheet…
Quiz• (True/False) Each thread owns its own heap and stack• (True/False) Hyper-threading involves only 1 hardware
thread, but many virtual threads• (True/False) Locks can be constructed by
enabling/disabling interrupts• (True/False) Finer-grained sharing leads to an increase
in concurrency which leads to better performance• (Short Answer) What is the section of code between
lock.acquire() and lock.release() called?