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 ? kernel-level threads V.S. user-level threads ?

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…

< Synchronization >

Critical section Semaphore Monitor

Critical Section

Critical section1. Entry section

{2. Critical section

}3. Exit section4. Remainder section

Critical section design requirements– 1. Mutual Exclusion– 2. Progress– 3. Bounded Waiting

Semaphore

Synchronization solutions– Mutex – Spinlock(busy waiting)– Counting semaphore/ Binary semaphore

Semaphore Implementation Issues

– Deadlock– Starvation

Semaphore Primitives Implementation

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( );}}

Synchronization

Three levels of abstraction for concurrent programming:– Hardware instructions

Atomic HW instruction ‘test_and_set’

– O/S primitives – Programming language constructs

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

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();}

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();

}}   

Classic Synchronization Problems

Bounded buffer problem Readers writers problem Dining philosophers problems

< 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

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.

Resource-allocation graph #1 R1 R2

. .

.

.

P1 P2 P3

R3

Resource-allocation graph #2

. .

.

.

.

P1 P2 P3

R3

P4

R1 R2

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

Deadlock Avoidance

Deadlock Prevention V.S. Deadlock Avoidance

Safe State Bankers Algorithm

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

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;}}

Synchronization Practice #1 – continuedboolean 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 guyflag = false;v = true;

}}while(v == true);wantin[i] = false;

}CSExit(){

flag = false;}

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.  

Synchronization Practice #2 - Answer

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);}

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);}

Synchronization Practice #3

Synchronization Practice #3 - Answer

Last Verdict…