Deadlock, Reader-Writer problem and Condi6on synchroniza6on - PowerPoint PPT Presentation

Deadlock, ¡Reader-­‑Writer ¡problem ¡ and ¡Condi6on ¡synchroniza6on ¡ Michelle ¡Ku>el ¡

Serial ¡versus ¡concurrent ¡ Sequential correctness is mostly concerned with safety properties: – ensuing that a program transforms each before-state to the correct after-state. Concurrent correctness is also concerned with safety, but the problem is much, much harder : – safety must be ensured despite the vast number of ways steps of concurrent threads can be be interleaved. Also,concurrent correctness encompasses a variety of liveness properties that have no counterparts in the sequential world.

Concurrent ¡correctness ¡ There ¡are ¡two ¡types ¡of ¡correctness ¡proper6es: ¡ Safety ¡proper+es ¡ ¡ ¡ The ¡property ¡must ¡ always ¡be ¡true. ¡ Liveness ¡proper+es ¡ ¡ ¡ The ¡property ¡must ¡eventually ¡become ¡true. ¡ ¡

Java ¡Deadlocks ¡ We ¡use ¡locking ¡to ¡ensure ¡safety ¡ • but ¡locks ¡are ¡inherently ¡vulnerable ¡to ¡ deadlock ¡ • indiscriminate ¡locking ¡can ¡cause ¡ lock-­‑ordering ¡ deadlocks ¡

Dining ¡philosophers ¡ Classic ¡problem ¡used ¡to ¡illustrate ¡deadlock ¡ – proposed ¡by ¡Dijkstra ¡in ¡1965 ¡ • a ¡table ¡with ¡five ¡silent ¡philosophers, ¡five ¡ plates, ¡five ¡forks ¡(or ¡chops6cks) ¡and ¡a ¡big ¡ bowl ¡of ¡spagheP ¡(or ¡rice). ¡ • Each ¡philosopher ¡must ¡alternately ¡think ¡ and ¡eat. ¡ ¡ unrealis6c, ¡ • Ea6ng ¡is ¡not ¡limited ¡by ¡the ¡amount ¡of ¡ spagheP ¡leR: ¡assume ¡an ¡infinite ¡supply. ¡ ¡ unsanitary ¡ • However, ¡a ¡philosophers ¡need ¡two ¡forks ¡ and ¡ to ¡eat ¡ interes6ng ¡ • A ¡fork ¡is ¡placed ¡between ¡each ¡pair ¡of ¡ adjacent ¡philosophers. ¡

Dining ¡philosophers ¡ • Basic ¡philosopher ¡loop: ¡ The ¡problem ¡is ¡how ¡to ¡ while True: � design ¡a ¡concurrent ¡ think() � algorithm ¡such ¡that ¡each ¡ get_forks() � philosopher ¡won't ¡ starve, ¡i.e. ¡can ¡forever ¡ eat() � con6nue ¡to ¡alternate ¡ put_forks() � between ¡ea6ng ¡and ¡ thinking. ¡ • Some ¡algorithms ¡result ¡in ¡some ¡or ¡all ¡of ¡the ¡ philosophers ¡dying ¡of ¡hunger…. ¡ deadlock ¡

Dining ¡philosophers ¡in ¡Java ¡ class Philosopher extends Thread { � � int identity; � � Chopstick left; Chopstick right; � � Philosopher(Chopstick left,Chopstick right){ � � � this.left = left; this.right = right; � � } � � public void run() { � poten+al ¡for ¡deadlock ¡ � � while (true) { � � � � try { � � � � � sleep(…); // thinking � � � � � right.get(); left.get(); // hungry � � � � � sleep(…) ; // eating � � � � � right.put(); left.put(); � � � � } catch (InterruptedException e) {} � � � } � � } � } �

Chops6ck ¡Monitor ¡ class Chopstick { � � Boolean taken=false; � � synchronized void put() { � � � taken=false; � � � notify(); � � } � � synchronized void get() throws � � � � � � InterruptedException � � { � � � while (taken) wait(); � � � taken=true; � � } � } �

Applet ¡for ¡diners ¡ for (int i =0; i<N; ++I) // create Chopsticks � � stick[i] = new Chopstick(); � for (int i =0; i<N; ++i){ � // create Philosophers � � phil[i]=new Philosopher(stick[(i-1+N%N],stick[i]); � � phil[i].start(); � } �

Dining ¡philosophers ¡cont. ¡ We ¡can ¡avoid ¡deadlock ¡by: ¡ • ¡controlling ¡the ¡number ¡of ¡philosophers ¡ (HOW?) ¡ • change ¡the ¡order ¡in ¡which ¡the ¡philosophers ¡ pick ¡up ¡forks. ¡(HOW?) ¡

Mo6va6ng ¡Deadlock ¡Issues ¡ Consider ¡a ¡method ¡to ¡transfer ¡money ¡between ¡bank ¡accounts ¡ ¡ class BankAccount { … synchronized void withdraw(int amt) {…} synchronized void deposit(int amt) {…} synchronized void transferTo(int amt, BankAccount a) { this.withdraw(amt); a.deposit(amt); } } No6ce ¡during ¡call ¡to ¡ a.deposit , ¡thread ¡holds ¡2 ¡locks ¡ – Need ¡to ¡inves6gate ¡when ¡this ¡may ¡be ¡a ¡problem ¡ Sophomoric ¡Parallelism ¡& ¡ 11 ¡ Concurrency, ¡Lecture ¡6 ¡

The ¡Deadlock ¡ For ¡simplicity, ¡suppose ¡ x ¡and ¡ y ¡are ¡sta6c ¡fields ¡holding ¡accounts ¡ Thread ¡2: ¡ y.transferTo(1,x) Thread ¡1: ¡ x.transferTo(1,y) acquire lock for x do withdraw from x acquire lock for y Time ¡ do withdraw from y block on lock for x block on lock for y Sophomoric ¡Parallelism ¡& ¡ 12 ¡ Concurrency, ¡Lecture ¡6 ¡

Deadly ¡embrace ¡ Simplest ¡form ¡of ¡deadlock: ¡ • Thread ¡A ¡holds ¡lock ¡L ¡while ¡trying ¡to ¡acquire ¡ lock ¡M, ¡while ¡thread ¡B ¡holds ¡lock ¡M ¡while ¡ trying ¡to ¡acquire ¡lock ¡L. ¡

Deadlock, ¡in ¡general ¡ A ¡deadlock ¡occurs ¡when ¡there ¡are ¡threads ¡ T1 , ¡…, ¡ Tn ¡such ¡ that: ¡ • For ¡ i =1,..,n-­‑1, ¡ Ti ¡is ¡wai6ng ¡for ¡a ¡resource ¡held ¡by ¡ T(i+1) ¡ • Tn ¡is ¡wai6ng ¡for ¡a ¡resource ¡held ¡by ¡ T1 ¡ In ¡other ¡words, ¡there ¡is ¡a ¡ cycle ¡ of ¡wai6ng ¡ – Can ¡formalize ¡as ¡a ¡graph ¡of ¡dependencies ¡ Deadlock ¡avoidance ¡in ¡programming ¡amounts ¡to ¡ employing ¡ ¡techniques ¡to ¡ensure ¡a ¡cycle ¡can ¡never ¡ arise ¡ slide ¡adapted ¡from: ¡Sophomoric ¡Parallelism ¡& ¡ 14 ¡ Concurrency, ¡Lecture ¡6 ¡

Deadlocks ¡in ¡Java ¡ Java ¡applica6ons ¡do ¡not ¡recover ¡from ¡deadlocks: ¡ • when ¡a ¡set ¡of ¡Java ¡threads ¡deadlock, ¡they ¡are ¡ permanently ¡out ¡of ¡commission ¡ • applica6on ¡may ¡stall ¡completely, ¡a ¡subsystem ¡ may ¡stall, ¡performance ¡may ¡suffer ¡ – …. ¡all ¡not ¡good! ¡ • If ¡there ¡is ¡poten6al ¡for ¡deadlock ¡it ¡may ¡actually ¡ never ¡happen, ¡but ¡usually ¡does ¡under ¡worst ¡ possible ¡condi6ons ¡ ¡so ¡we ¡need ¡to ¡ensure ¡that ¡it ¡can’t ¡happen ¡

Back ¡to ¡our ¡example ¡ Op6ons ¡for ¡deadlock-­‑proof ¡transfer: ¡ 1. Make ¡a ¡smaller ¡cri6cal ¡sec6on: ¡ transferTo ¡not ¡synchronized ¡ Exposes ¡intermediate ¡state ¡aRer ¡ withdraw ¡before ¡ deposit – May ¡be ¡okay, ¡but ¡exposes ¡wrong ¡total ¡amount ¡in ¡bank ¡ – 2. Coarsen ¡lock ¡granularity: ¡one ¡lock ¡for ¡all ¡accounts ¡allowing ¡ transfers ¡between ¡them ¡ Works, ¡but ¡sacrifices ¡concurrent ¡deposits/withdrawals ¡ – 3. Give ¡every ¡bank-­‑account ¡a ¡unique ¡number ¡and ¡always ¡acquire ¡ locks ¡in ¡the ¡same ¡order ¡ En/re ¡program ¡ should ¡obey ¡this ¡order ¡to ¡avoid ¡cycles ¡ – Code ¡acquiring ¡only ¡one ¡lock ¡is ¡fine ¡ – Sophomoric ¡Parallelism ¡& ¡ 16 ¡ Concurrency, ¡Lecture ¡6 ¡

Ordering ¡locks ¡ class BankAccount { … private int acctNumber; // must be unique void transferTo(int amt, BankAccount a) { if(this.acctNumber < a.acctNumber) synchronized(this) { synchronized(a) { this.withdraw(amt); a.deposit(amt); }} else synchronized(a) { synchronized(this) { this.withdraw(amt); a.deposit(amt); }} } } Sophomoric ¡Parallelism ¡& ¡ 17 ¡ Concurrency, ¡Lecture ¡6 ¡

Lock-­‑ordering ¡deadlocks ¡ • occur ¡when ¡two ¡threads ¡a>empt ¡to ¡acquire ¡the ¡ same ¡locks ¡in ¡a ¡different ¡order ¡ • A ¡program ¡will ¡be ¡free ¡of ¡lock-­‑ordering ¡deadlocks ¡ if ¡all ¡threads ¡acquire ¡the ¡locks ¡they ¡need ¡in ¡a ¡ fixed ¡global ¡order ¡ – requires ¡global ¡analysis ¡of ¡your ¡programs ¡locking ¡ behaviour ¡ • A ¡program ¡than ¡ never ¡acquires ¡more ¡than ¡one ¡ lock ¡at ¡a ¡+me ¡will ¡also ¡never ¡deadlock, ¡but ¡oRen ¡ imprac6cal ¡

Another ¡example ¡ From ¡the ¡Java ¡standard ¡library ¡ class StringBuffer { private int count; private char[] value; … synchronized append(StringBuffer sb) { int len = sb.length(); if(this.count + len > this.value.length) this.expand(…); sb.getChars(0,len,this.value,this.count); } synchronized getChars(int x, int, y, char[] a, int z) { “copy this.value[x..y] into a starting at z ” } } Sophomoric ¡Parallelism ¡& ¡ 19 ¡ Concurrency, ¡Lecture ¡6 ¡