CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric...
Transcript of CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric...
![Page 1: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/1.jpg)
CS 140: Midterm Review 6th February 2015
![Page 2: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/2.jpg)
Administrivia
• Project 2 was due at noon • Project 3 will be due on Feb 27th -‐ Review Session on the 13th
• Midterm on Monday -‐ Open notes + any material that you print -‐ No electronic devices -‐ No textbook
2
![Page 3: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/3.jpg)
Midterm Coverage
• Processes and Threads • Concurrency • Scheduling • Virtual Memory • Synchronization • Memory Allocation
3
![Page 4: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/4.jpg)
Processes and Threads
• OSes need to provide some mechanisms for multitasking: preemption and memory protection
4
![Page 5: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/5.jpg)
Processes and Threads
• Provide two examples of an application that beneKits from multithreading, and two examples where multithreading does not provide better performance than a single-‐threaded solution.
5
![Page 6: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/6.jpg)
Processes and Threads • Yay Mul5threading:
– Applica5on with User interface. UI thread separate from background processing thread gives beIer responsiveness. – Any program with heavy CPU usage along with I/O.
• Boo Mul5threading: – Programs with heavy I/O, hardly any CPU usage. BoIleneck will always be at I/O, threading will only add more overhead. – Mainly sequen5al programs that modify small chunks of data. Synchroniza5on overhead will outweigh threading benefits.
6
![Page 7: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/7.jpg)
It’s all about context
• User -‐> Kernel? – Syscall, Page Fault
• User -‐> Interrupt Handler? – Hardware/Software Interrupt
• User/Process -‐> User? – Return
7
![Page 8: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/8.jpg)
Kernel and User Threads
• Kernel threads: Faster than a process (still pretty heavy though), kernel does everything for you, every operation has to go through the kernel, one-‐size Kits all.
• User threads: User library keeps a list of runnable threads, all threads belong to the process that started them, can be custom-‐built for particular applications
8
![Page 9: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/9.jpg)
Concurrency • What is Sequential Consistency? – We often assume that our machines support it – But they mostly don’t. – SC prevents a lot a compiler optimizations and makes performance hardware a lot harder to design.
– Other models? (refer to slides) • How do we prevent data races? – Critical Sections! (These will have to guarantee mutual exclusion, progress and bounded waiting times)
– You’ve seen different synchronization primitives in your Pintos projects
9
![Page 10: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/10.jpg)
Concurrency Initialization int a = 4; int b = 0; int c = 0; Thread 1 Thread 2 if (a < 0) { b = 10;
c = b – a; a = -‐3; } else {
c = b + a; }
What are the possible values for c after both threads complete? Assume that reads and writes of variables are atomic, and that the order of statements within each thread is preserved in the code generated by the C compiler (i.e., this code is sequentially consistent)
10
![Page 11: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/11.jpg)
Concurrency Initialization int a = 4; int b = 0; int c = 0; Thread 1 Thread 2 if (a < 0) { b = 10;
c = b – a; a = -‐3; } else {
c = b + a; }
Ans: 4, 7, 13, 14, -‐3
11
![Page 12: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/12.jpg)
Concurrency
Consider the following three threads, where resource1, resource2, resource3 are generic resources that only one thread can hold at a time. Can we have deadlock? Remember that we have 4 conditions for deadlock: -‐ Limited Access (Mutual Exclusion) -‐ No preemption -‐ Multiple Independent Requests -‐ Circularity in request graph
12
![Page 13: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/13.jpg)
a () { acquire(resource1); acquire(resource2); doWorkA(); release(resource2); release(resource1);
} b (){
acquire(resource2); acquire(resource3); doWorkB(); release(resource3); release(resource2);
} c () {
acquire(resource3); acquire(resource1); doWorkC(); release(resource1); release(resource3);
}
13
![Page 14: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/14.jpg)
a () { acquire(resource1); acquire(resource2); doWorkA(); release(resource2); release(resource1);
} b (){
acquire(resource2); acquire(resource3); doWorkB(); release(resource3); release(resource2);
} c () {
acquire(resource3); acquire(resource1); doWorkC(); release(resource1); release(resource3);
}
Yep! This could deadlock. Mutual Exclusion. Each of the resources are mutually exclusive and only one thread can access at a 5me. No Preemp5on. Resources cannot be forcibly taken back. Mul5ple Independent Requests. Each of the resources is requested individually Circularity. A can wait on B, who can wait on C, who in turn can wait on A
14
![Page 15: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/15.jpg)
Scheduling • What do we care about? Throughput, Turnaround Time, Response Time, CPU Utilization, Waiting Times
• Scheduling Algorithms:
– FCFS (FIFO) – Shortest Job First (can also be SRTF) – Round-‐Robin – Priority Scheduling – Real-‐time Scheduling
15
![Page 16: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/16.jpg)
Scheduling (a) Describe a CPU scheduling algorithm that guarantees that
no process will starve given a Kinite number of processes. (b) Describe a CPU scheduling algorithm that can result in starvation. Provide an example workload that will result in starvation.
16
![Page 17: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/17.jpg)
Scheduling (a) Describe a CPU scheduling algorithm that guarantees that
no process will starve given a Kinite number of processes. Round-‐Robin Schedulers with time-‐slices and preemption
(b) Describe a CPU scheduling algorithm that can result in starvation. Provide an example workload that will result in starvation. SJC with a lot of short jobs will starve long running software
17
![Page 18: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/18.jpg)
Virtual Memory HW
• Issues of protection, transparency, resources -‐ Give each program its own virtual address space
• Segmentation: base + bounds registers -‐ Simple, not transparent, external fragmentation
• Paging: map virtual pages to physical pages -‐ SimpliKies allocating and freeing, transparent, internal fragmentation
• x86 page translation -‐ An interesting case. Has segmentation AND paging.
18
![Page 19: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/19.jpg)
Virtual Memory OS • We typically have more virtual memory than actual physical memory.
• But now, we need to decide what to fetch and what to eject – FIFO – LRU – Clock Algorithm – A few more
• Other issues: Thrashing, Working Sets, Memory Mapped Files
19
![Page 20: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/20.jpg)
Virtual Memory The following Kigure shows the address translation mechanism used for 64-‐bit mode in Intel x86 processors. Starting with a 48-‐bit virtual addresses, it uses 4 levels of page table to translate the address to a 52-‐bit physical address. Each page table entry is 8 bytes long.
20
![Page 21: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/21.jpg)
If the page size is increased, the number of levels of page table can be reduced. How large must pages be in order to translate 48-‐bit virtual addresses with only 2 levels of page table? Draw the address transla5on mechanism corresponding to this page size.
21
![Page 22: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/22.jpg)
Let the number of offset bits be x and number of bits to index into the page tables by y: Total number of bits = 48, so.. 2y + x = 48 Each page table needs to Kit into a page, so.. (2^y)*8 = 2^x ⇒ y = 15; ⇒ x = 18; ⇒ Page = (2^18) bytes = 256 kB per page
22
![Page 23: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/23.jpg)
Synchronization
• Implemen5ng shared locks – The mul5ple readers, single writer problem
• Dealing with ordering requirements can be hard – The test&set spinlock could be useless if we don’t compensate for no sequen5al consistency
• Memory barriers in locks are useful for relaxed consistency models
• Performance needs caches, and that in turn needs coherence.
23
![Page 24: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/24.jpg)
Synchronization
• cc-‐NUMA and spinlocks issues – Spinlocks are unfair and cause a lot of trafKic – Either avoid spinlocks completely, or spin on a lock in local memory
• Locks and scheduling issues – Expensive to switch to the kernel – futex: ask kernel to sleep only if memory has changed
24
![Page 25: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/25.jpg)
Memory Allocation • Dynamic allocation’s main problem is fragmentation – different lifetimes, different sizes
• Decisions: where in free memory to put a block? – There will always be pathological cases – Best Kit: allocate to leave the smallest fragment – First Kit: pick the best block that Kits
• Other Stuff: – memory usage patterns (peaks, ramp, plateaus) – fault + resumption = power – distributed shared memory – garbage collection – reference counting
25
![Page 26: CS#140:#MidtermReview# · resource1,#resource2,#resource3aregeneric resources#that#only#one#thread#can#hold#at#a#time.## # Can#we#have#deadlock?#Remember#that#we#have#4# conditionsfordeadlock:](https://reader035.fdocuments.net/reader035/viewer/2022071020/5fd4741d0f7a9e4a00798167/html5/thumbnails/26.jpg)
Best Of Luck!
26