CS 162 Discussion Section Week 2 (9/16 – 9/20)

1. CS 162Discussion SectionWeek 2(9/16 – 9/20)

2. Who am I? Kevin Klues cs162-ta@inst.eecs.berkeley.edu http://www.cs.berkeley.edu/~klueska Office Hours: 12:30pm-2:30pm Mondays @ Soda 7th Floor Alcove

3. 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)

4. 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

5. Project Grading • Design docs [40 points] • First draft [10 points] • Design review [10 points] • Final design doc [20 points] • Code [60 points]

6. 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.

7. 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

8. Design Document Structure Each part of the project should be explained using the following structure • Overview • Correctness Constraints • Declarations • Descriptions • Testing Plan

9. Design Doc Length • Keep under 15 pages • Will dock points if too long!

10. 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

11. 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

12. 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/groupXX git: https://github.com/Berkeley-CS162/groupXX

13. Project Questions?

14. 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?

15. Lecture Review

16. Putting it together: Processes Process 1 Process 2 Process N • 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) Mem. Mem. Mem. … IO state IO state IO state CPU state CPU state CPU state CPU sched. OS 1 process at a time CPU (1 core)

17. Putting it together: Threads Process 1 Process N threads threads • Switch overhead: low(only CPU state) • Thread creation: low • Protection • CPU: yes • Memory/IO: No • Sharing overhead: low (thread switch overhead low) Mem. Mem. IO state … IO state … … CPU state CPU state CPU state CPU state CPU sched. OS 1 thread at a time CPU (1 core)

18. Why Processes & Threads? Goals: • Multiprogramming: Run multiple applications concurrently • Protection: Don’t want a bad application to crash system! Solution: Process: unit of execution and allocation • Virtual Machine abstraction: give process illusion it owns machine (i.e., CPU, Memory, and IO device multiplexing) Challenge: • Process creation & switching expensive • Need concurrency within same app (e.g., web server) Solution: Thread: Decouple allocation and execution • Run multiple threads within same process

19. 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

20. 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!

21. Review: Two Thread Yield Example Thread T Thread S A A • Consider the following code blocks: proc A() { B(); } proc B() { while(TRUE) { yield(); } } • Suppose we have two threads: • Threads S and T B(while) B(while) yield yield kernel_yield kernel_yield run_new_thread run_new_thread switch switch

22. 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

23. 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

24. Better Implementation of Locks by Disabling Interrupts • Key idea: maintain a lock variable and impose mutual exclusion only during operations on that variable int 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; }

25. contextswitch contextswitch 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 interrupts Thread AThread B . . disable ints sleep . . sleep return enable ints . . yield returnenable ints disable int yield

26. Worksheet…

28. 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?