Concurrency IntroInterleaving (multiprogramming) produces many problemsRelative speed of two processes is not generally predictableMust be careful when sharing global resourcesO.S. Data Structures, Files, etc.Protecting system from bad processesDifficult to allocate resources optimally if a process is blocked or suspendedErrors tend to be difficult to findOften dependent on exact timingExample: Interrupt A requires 1ms to process, but error occurs if interrupt B happens during that periodMultiprocessing increases problems, but not drastically

Concurrency ProblemBook uses different exampleAssume P1 repeats:wait for an event (car goes by)temp = count + 1count = tempAssume P2 repeats:wait for some period of timedisplay countcount = 0What happens if P2 is interrupted after display count and P1 does its loop?What happens if P1 is interrupted after temp = count + 1 and P2 does its loop?

DefinitionsMutual Exclusion Making sure two processes cant both have a resourceCritical Section The area of a program where a resource is being usedDeadlock When two or more processes halt, unable to proceedP1 is using A, needs BP2 is using B, needs AStarvation A process waits indefinitely for a resourceP1 using A, P2 and P3 wait for AP2 gets A when P1 doneP1 comes in, P1 and P3 wait for A

Process InteractionTable 5.1, pg. 203Unaware of each otherIndependent processesNot intended to work togetherExample: Netscape and WordCompete for resourcesPrinter, files, CPU timeO.S. must manage mutual exclusion, avoid deadlock and starvationIndirectly aware of each otherShare read/write access to a objectExample: Word and ExcelCooperate in using the shared objectMust also worry about data coherenceDirectly aware of each otherDesigned to work together, communicateExample: Background printing process that is part of a word processing program

Concurrency RequirementsMutual Exclusion must be enforcedOnly one process at a time may be accessing the critical sectionA process can halt outside the critical section without harmNo deadlock or starvation (a process that wants to will eventually get into critical section)If no process is in a critical section, a process requesting entry must be allowed to enter without delayNo assumptions about number or relative speed of processes or processorsA process remains inside its critical section for a limited period of timeCan be solved by software or hardware, with or without O.S. support

Software ApproachesTurn variable (figure 5.2a)P0P1while (turn != 0) /**/;while (turn != 1) /**/;critical sectioncritical sectionturn = 1;turn = 0;Shared variable turn indicates who is allowed to enter next, can enter if turn = meOn exit, point variable to other processDeadlock if other process never entersBusy Flag (figure 5.2b)P0P1while ( flag[1] ) /**/;while ( flag[0] ) /**/;flag[0] = true;flag[1] = true;critical sectioncritical sectionflag[0] = false;flag[1] = false;Each process has a flag to indicate it is in the critical sectionFails mutual exclusion if processes are in lockstep

Software ApproachesBusy Flag Modified (figure 5.2c)P0P1flag[0] = true;flag[1] = true;while ( flag[1] ) /**/;while ( flag[0] ) /**/;critical sectioncritical sectionflag[0] = false;flag[1] = false;Deadlocks if processes are in lockstepBusy Flag Again (figure 5.2d)P0P1flag[0] = true;flag[1] = true;while ( flag[1] )while ( flag[0] ){{flag[0] = false; flag[1] = false;delay delayflag[0] = false; flag[1] = false;}}critical sectioncritical sectionflag[0] = false;flag[1] = false;Livelock if processes are in lockstep

Software ApproachesDekkers Algorithm (figure 5.3a)Use flags for mutual exclusion, turn variable to break deadlockHandles mutual exclusion, deadlock, and starvation Petersons Algorithm (figure 5.3b)P0P1flag[0] = true;flag[1] = true;turn = 1;turn = 0;while ( flag[1] &&while ( flag[0] &&turn == 1 ) /**/; turn == 0 ) /**/;critical sectioncritical sectionflag[0] = false;flag[1] = false;What if we have more than two processes?Some have multi-process extensionsCan use a tournament

Hardware SupportDisable InterruptsOnly works for uniprocessorsDelays response to external eventsSpecial InstructionsMust appear as a indivisible unit to other processorsTest and Set If V is 0, set to 1 and return true, else return falseMay let user specify test/set valuesExchange Swap reg and memoryExample uses: figure 5.5a, bPropertiesSimpleOne variable per critical sectionOften use busy waitingPossibility of deadlock or starvation

SemaphoresFirst defined by DijkstraInitialize a counterMust be non-negative (often 0 or 1)Operations (fig 5.6, pg 218)Wait (P) Decrement counter, then block if < 0, else continueSignal (V) Increment counter, wake up a blocked process if now 0No requirement on who wakes up, but generally dont want starvation to occurCan define a semaphore that wakes processes strictly in FIFO orderBinary Semaphore Can only take on values 0, 1 (figure 5.7)Can fairly easily use one to implement the other

SemaphoresProvide a very useful form of mutual exclusionInitialize semaphore s to 1do forever:wait(s)critical sectionsignal(s)Implementing Wait/SignalHardware primitives (Fig. 5.17, pg 229)Busy wait only occurs inside wait/signalSoftware methodsSemaphore internals are the critical section for the low-level methodsGenerally these are short enough to be acceptableMeaning of count:if count 0 : how many processes can call wait() without blockingif count < 0 : how many processes are currently blocked on this semaphore

Producers & ConsumersOne process produces some type of dataThe other process consumes that dataData stored in a shared buffer (infinite size)Require mutual exclusion to access bufferProducer (Figure 5.13, page 225)do foreverproduce itemwait(s)append to queuen++if n = 1 then signal(delay)signal(s)Consumerwait(delay)do foreverwait(s)remove from queuen--m = nsignal(s)if m = 0 then wait(delay)Solutions available for limited buffer version

Barbershop Problem3 barbers, each with a barber chairHaircuts may take varying amounts of timeSofa can hold 4 customers, max of 20 in shop (figure 5.18, page 230)Customers wait outside if necessaryWhen a chair is empty:Customer sitting longest on sofa is servedCustomer standing the longest sits downAfter haircut, go to cashier for paymentOnly one cash registerAlgorithm has a separate cashier, but often barbers also take paymentThis is also a critical section

Fair Barbershop (figure 5.20)See table 5.3 for purpose of each semaphore

program barbershop2;varmax_capacity: semaphore (:=20);sofa: semaphore (:=4);barber_chair, coord: semaphore (:=3);mutex1, mutex2: semaphore (:=1);cust_ready, leave_b_chair, payment, receipt: semaphore (:=0)finished: array [1..50] of semaphore (:=0);count: integer;

procedure customer; procedure barber;procedure cashier;var custnr: integer; var b_cust: integerbeginbegin begin repeat wait (max_capacity ); repeat wait( payment ); enter shop; wait( cust_ready ); wait( coord ); wait( mutex1 ); wait( mutex2 ); accept payment; count := count + 1; dequeue1( b_cust ); signal( coord ); custnr := count; signal( mutex2 ); signal( receipt ); signal( mutex1 ); wait( coord ); forever wait( sofa ); cut hair;end; sit on sofa; signal( coord ); wait( barber_chair ); signal( finsihed[b_cust] ); get up from sofa; wait( leave_b_chair ); signal( sofa ); signal( barber_chair ); sit in barber chair; forever wait( mutex2 ); end; enqueue1( custnr ); signal( cust_ready ); signal( mutex2 ); wait( finished[custnr] ); leave barber chair; signal( leave_b_chair ); pay; signal( payment ); wait( receipt ); exit shop; signal( max_capacity );end;

MonitorsSemaphores tend to require Wait/Signal operations spread throughout the codeMonitorProposed by Hoare in 1974Local data variables only accessible within the monitors proceduresEnter by invoking one of the defined proceduresOnly one process may be in the monitor at a timeIf two processes try to enter, one is forced to waitA process may enter the monitor, then wait for a event to happen.While waiting, other processes can enterInternal routines cwait and csignal

Improving MonitorsHoares design requires a process waiting must be immediately woken upEvents may change if others come inRequires multiple context switches if signalling process isnt finishedNotify and BroadcastCreated by Lampson and RedellReplaces csignal with cnotifyExecuting process continues runningWaiting process resumed when convenient, must recheck conditionIncludes timeout to avoid starvationcbroadcast Resume everybodyDont have to decide who needs to wakeLess sensitive to incorrect signals

Message PassingBased on two primitives:send( destination, message )receive( source, message )SynchronizationBlocking Send, Blocking ReceiveWait until both are ready (rendezvous)Nonblocking Send, Blocking ReceiveSender doesnt wait, but receiver doesUseful in sending multiple messagesUse replies to verify message receiptNonblocking Send and ReceiveIf no messages, returns immediatelyCan allow test for waiting messagesAddressingDirect Provide ID of destinationIndirect Send to a mailboxCan vary mailbox/process matching

MessagesFormat (Fig 5.25, pg 245)Short, Fixed-length is simpleVariable-length more flexibleQueuing disciplineFIFO SimpleMay want priorities so that some messages are more important than othersSynchronizationMust use semaphores or some other mutual exclusion for the send and receive subroutinesIf multiple processes wait on a mailbox, only one receives a messageEasily extended to multiprocessor or distributed systems

Mutual ExclusionCan use messages to implement mutual exclusion (fig 5.26, pg 246)Initialize mailbox to hold count (0, 1, 2, ) messagesUse blocking receive to get a message, then allowed to enter critical section (i.e., wait)Send message to the mailbox when done (i.e., signal)Can use messages to implement a bounded-buffer producer-consumer problem (fig 5.27, page 247)a mailbox with one message for each item that may be produceda mailbox with one message for each item that may be consumedMessage can include item

Reader/Writer ProblemAssume we have a shared data areaAny number of readers may simultaneously read the dataOnly one writer may modify the data at a timeIf the data is being modified, nobody may read the dataWe can use a general mutual exclusion solutionFails to permit allowable operations like two readers at onceNote this is distinct from producer/consumer problemConsumer has to adjust queue contents and pointers

Reader-Priority SolutionFigure 5.28, page 249Semaphores: x, wsem = 1Readerwait(x);readcount++;if ( readcount == 1 ) wait(wsem);signal(x);Reader C.S.wait(x);readcount--;if ( readcount==0 ) signal(wsem);signal(x);Writerwait(wsem);Writer C.S.signal(swim);Writers can be starved if there is a continuous sequence of readers

Writer-Priority SolutionFigure 5.29, page 251Semaphores: x, y, z, wsem, rsem = 1System states:Readers only: wsem setWriters only: wsem, rsem set, writers queue on wsemReader(s) in c.s.: wsem set by reader, rsem set by writer, writers queue on wsem, one read on rsem, other readers queue on zWriter in c.s.: wsem, rsem set by writer, writers queue on wsem, one read on rsem, other readers queue on zReaderwait(z); wait(rsem); wait(x);readcount++;if ( readcount == 1 ) wait(wsem);signal(x); signal(rsem); signal(z);Reader C.S.wait(x);readcount--;if ( readcount==0 ) signal(wsem);signal(x);Writerwait(y);writecount++;if ( writecount == 1 ) wait(rsem);signal(y);wait(wsem);Writer C.S.signal(wsem);wait(y);writecount--;if ( writecount == 0 ) signal(rsem);signal(y);Readers can be starved in this case

Message-passing SolutionGives writers priorityUse a controller process to manage shared dataMeaning of count:Initialize to 100 (> max # of readers)Count > 0 means no writers waiting, may have readersCount = 0 means one outstanding write requestCount < 0 means write request(s) outstanding, waiting for readers to exitReader(i)rmsg = i;send( readrequest, rmsg ); receive( mbox[i], rmsg ); reader C.S.rmsg = i;send( finished, rmsg );

Writer(j)rmsg = j;send( writerequest, rmsg );receive( mbox[j], rmsg );writer C.S.rmsg = j;send( finished, rmsg ); Controllerdo forever if ( count > 0 ) if ( !empty( finished ) ) receive( fininshed, msg ); count++; else if ( !empty( writerequest ) ) receive( writerequest, msg ); writer_id = msg.id count -= 100; else if ( !empty( readrequest ) ) receive( readrequest, msg ); count--; send( msg.id, OK );if ( count == 0 ) send( writer_id, OK ); receive( finished, msg ); count = 100;while ( count < 0 ) receive( finished, msg ); count++;

Alternating SolutionSemaphores: mutex = 1, readsleep, writesleep = 0Readcount = # of readers in c.s.Readers will not enter if a writer is waitingLast reader to exit will wake up a waiting writerExiting writer will wake up all waiting readersReaderwait(mutex);if ( writewait > 0 ) { readwait++; signal(mutex); wait(readsleep); }else { readcount++; signal(mutex); }Reader C.S.wait(mutex);readcount--;if ( readcount==0 && writewait > 0 ){ writewait--; signal(writesleep); }else signal(mutex);Writerwait(mutex);if ( readcount > 0 ) { writewait++; signal(mutex); wait(writesleep); }Writer C.S.if ( readwait > 0 )while ( readwait > 0 ){ readwait--; readcount++; signal(readsleep); }signal(mutex);else if ( writewait > 0 ) { writewait--; signal(writesleep); }else signal(mutex);