CS 162Discussion Section

Week 2(9/16 – 9/20)

Who am I?

Kevin Kluescs162-ta@inst.eecs.berkeley.eduhttp://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 SA

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

contextswitch

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?