1 / 26

COMS 414 - Prelim 1 Review Session

COMS 414 - Prelim 1 Review Session. Yejin Choi ychoi@cs.cornell.edu Daniel Williams djwill@cs.cornell.edu. < Processes & Threads >. program V.S. process ? process V.S. thread ? kernel space V.S. user space? o/s processes V.S. user processes ?

aminia
Télécharger la présentation

COMS 414 - Prelim 1 Review Session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. COMS 414 - Prelim 1 Review Session Yejin Choi ychoi@cs.cornell.edu Daniel Williams djwill@cs.cornell.edu

  2. < Processes & Threads > • program V.S. process ? • process V.S. thread ? • kernel space V.S. user space? • o/s processes V.S. user processes ? • kernel-level threads V.S. user-level threads ?

  3. Multitasking (or multithreading…) • What is a system call? • What is a context switch? • What states may a process be in? • What is a race condition? • What is PCB? • Multiprocessor & MultiThreading… • HyperThreading…

  4. < Synchronization > • Critical section • Semaphore • Monitor

  5. Critical Section • Critical section 1. Entry section { 2. Critical section } 3. Exit section 4. Remainder section • Critical section design requirements • 1. Mutual Exclusion • 2. Progress • 3. Bounded Waiting

  6. Semaphore • Synchronization solutions • Mutex • Spinlock(busy waiting) • Counting semaphore/ Binary semaphore • Semaphore • Implementation Issues • Deadlock • Starvation

  7. Busy waiting : Wait(S) { while(S<=0) ; // no-op S--; } Signal(S) { S++; } Block & Wakeup from CPU scheduler: Wait(S) { S--; if( S<0 ) { block( );} } Signal(S) { S++; if( S<=0 ) { wakeup( );} } Semaphore Primitives Implementation

  8. Synchronization • Three levels of abstraction for concurrent programming: • Hardware instructions • Atomic HW instruction ‘test_and_set’ • O/S primitives • Programming language constructs

  9. Monitors • monitor • condition variables • condition variables V.S. semaphores • Condition variable signal( ) … resumes exactly only one suspended process … if no process suspended, no effect at all • Semaphore signal( ) … always affect the state of the semaphore … by increasing resource counter

  10. Sample Monitor Code (….from HW $2-#4-b) monitor readersnwriters { int rcnt = 0, rwaiting = 0, wcnt = 0, wwaiting = 0;     condition wantread, wantwrite; int enter_cnt = 1; // the semaphore’s “value” condition wantenter; // . . . and here’s its wait queue public StartRead() { –-enter_cnt; // this version is allowed to go negative if(enter_cnt < 0) // wait if someone else is inside wantenter.wait();  if(wcnt > 0 || wwaiting > 0) { ++rwaiting; wantread.wait(); --rwaiting; } rcnt++; wantread.signal(); if(++enter_cnt <= 0 && rcnt < 4) // signal the next guy, if any wantenter.signal(); } public EndRead() { if(rcnt == 4) wantenter.signal();  if(--rcnt == 0) wantwrite.signal();}

  11. Sample Monitor Code – continued public StartWrite() { –-enter_cnt; // just like StartRead if(enter_cnt < 0) wantenter.wait();   if(wcnt == 1 || rcnt > 0) { ++ wwaiting; wantwrite.wait(); --wwaiting; }   wcnt = 1; if(++enter_cnt <= 0) wantenter.signal();}public EndWrite() { wcnt = 0; if(rwaiting > 0) wantread.signal(); else wantwrite.signal();} }

  12. Classic Synchronization Problems • Bounded buffer problem • Readers writers problem • Dining philosophers problems

  13. < Deadlock > • Deadlock V.S. Livelock • Necessary conditions • Mutual Exclusion, Hold and Wait, No Preemption, Circular Wait • Resource Allocation Graph / Wait-For Graph • Deadlock Prevention • Ensure one of ‘necessary conditions’ do not hold • Deadlock Avoidance • Safe State, Resource-Allocation Graph Algorithm, Banker’s Algorithms

  14. Livelock (/li:v'lok/ from www.hyperdictionary.com…) • When two or more processes continuously change their state in response to changes in the other process(es) without doing any useful work. • This is similar to deadlock in that no progress is made but differs in that neither process is blocked or waiting for anything. • A human example of livelock would be two people who meet face-to-face in a corridor and each moves aside to let the other pass, but they end up swaying from side to side without making any progress because they always move the same way at the same time.

  15. . . P1 P2 P3 . . R3 Resource-allocation graph #1 R1 R2

  16. Resource-allocation graph #2 R1 R2 . . P1 P2 P3 . . . R3 P4

  17. Deadlock Prevention Make sure that one of the necessary conditions does not hold: 1. Mutual exclusion 2. Hold and Wait 3. No Pre-Emption 4. Circular Wait

  18. Deadlock Avoidance • Deadlock Prevention V.S. Deadlock Avoidance • Safe State • Bankers Algorithm

  19. < How to Prepare Prelim > • Make sure to review homework problem sets. • Practice writing synchronization code on your own. • Rather than reading every single line of the text book, find out key ideas and topics, and try to explain them in your own words. • http://www.cs.cornell.edu/Courses/cs414/2003fa/ • http://www.cs.cornell.edu/Courses/cs414/2002fa/

  20. Synchronization Practice #1 HW $1-#4. boolean waiting [2] = {false, false}; boolean flag = false; CSEnter() { waiting[i] = true; boolean v = true; while (waiting[i] && v) { v = test_and_set(flag); } waiting[i] = false; }  CSExit() { if (waiting[j]) { waiting[j] = false; } else { flag = false; } }

  21. boolean flag = false; boolean wantin[2] = {false, false }; int turn = 0; CSEnter() { boolean v; wantin[i] = true; turn = j; do { v = test_and_set(flag); if(v == false && wantin[j] && turn == j) { // I got in first, but need to defer to the other guy flag = false; v = true; } } while(v == true); wantin[i] = false; } CSExit() { flag = false; } Synchronization Practice #1 – continued

  22. Synchronization Practice #2 HW. $2-#4-a) A CD or DVD burner device can support one process writing to the device, or a maximum of 4 processes concurrently reading from the device.   Using semaphores, implement procedures StartRead, StartWrite, EndRead and EndWrite so that (1) these limits will be enforced, and (2) Processes are allowed to access the device in a strict FIFO order.  For example if P2 calls StartWrite and has to wait, and then P4 calls StartRead, P2 gets to write before P4 gets to read.  

  23. Synchronization Practice #2 - Answer EndRead(){ wait(mutex); if(rcnt == 4) signal(wait_queue); if(--rcnt == 0) signal(writer); signal(mutex); }StartWrite(){ wait(wait_queue); wait(writer); signal(wait_queue);} EndWrite(){ signal(writer);} Semaphore wait_queue = 1;Semaphore mutex = 1;Semaphore writer = 1;int rcnt = 0; StartRead(){ wait(wait_queue); wait(mutex); if(rcnt == 0) wait(writer); rcnt++; signal(mutex); if(rcnt < 4) signal(wait_queue);}

  24. Synchronization Practice #3

  25. Synchronization Practice #3 - Answer

  26. Last Verdict…

More Related