Hardware/Software Deadlock Avoidance for Multiprocessor Multiresource System-on-a-Chip

Transcription

1 P1 Q1 Hardware/Software Deadlock Avoidance for Multiprocessor Multiresource System-on-a-Chip Q2 P2 Dissertation Defense By Jaehwan Lee Advisor: Vincent J. Mooney III School of Electrical and Computer Engineering Georgia Institute of Technology Atlanta, GA USA Georgia Institute of Technology

2 P1 Q1 Outline Q2 P2 Motivation and Objective Background and Prior Work Proofs about Deadlock Detection Unit Deadlock Avoidance Unit Parallel Banker s s Algorithm Unit Integration into δ hardware/software RTOS framework Conclusion Georgia Institute of Technology

3 Motivation - Technology Trends Future SoC s Multiple heterogeneous processors (tens of processes) Multiple on-chip hardware resources DSP, FFT, MPEG, GPS, Shared Memory, etc Examples Xilinx Virtex-II Pro FPGA includes multiple PowerPC Broadcom BCM1400 includes multiple MIPS64 Processes in such an SoC Dynamically request and use resources May end up in deadlock Current embedded system or single processor system Typically ignored today HW SW RTOS SoC: System on Chip Georgia Institute of Technology

4 Motivation - Does deadlock really matter? Examples of future real-time systems Human-like robot with multiple processes In case of deadlock Damage People get injured Law-suits Mars Rover In case of deadlock Money loss Time loss Industrial control Cars Even if low probability of deadlock, prefer no deadlock whatsoever Georgia Institute of Technology

5 Objective - Problem, Solution and Goal Problem How to deal with deadlock? Goal Allow software to make requests in any order Grant as many resources as possible Avoid deadlock correctly and quickly Solution A hardware/software mechanism of deadlock avoidance, easily applicable to Real-Time Multiprocessor System-on on-a-chip (SoC) design Georgia Institute of Technology

6 Background: Definitions Definition of Deadlock A system has a deadlock iff the system has a set of processes, each of which is blocked, waiting for requirements that can never be satisfied P1 Q1 Q2 P Georgia Institute of Technology

7 Background: Definitions Definition of Livelock Livelock is a situation where a request for a resource is repeatedly denied and possibly never accepted because of the unavailability of the resource, resulting in a stalled process, while the resource is made available for other process(es) which make progress Georgia Institute of Technology

8 Background: Definitions Definition of Deadlock Avoidance A way of dealing with deadlock where resource usage is dynamically controlled not to reach deadlock (i.e., on the fly, resource usage is controlled to ensure that there can never be deadlock) Georgia Institute of Technology

9 Background: Definitions Definition of a Safe Sequence A safe sequence is an enumeration p 1, p 2,, p n of all processes in the system, such that for each i=1, 2,,, n, the resources that p i may request are a subset of the union of resources currently available plus resources currently held by p 1, p 2,,, p i Georgia Institute of Technology

10 Background: Terms Request deadlock (R-dl) A deadlock situation directly caused by a request Assumptions: No restriction on resource usage (i) P1 requires either Q1, Q2, or both depending on software flow (ii) P2 also requires either Q1, Q2, or both (iii) We don t t know in advance When P1 and P2 take flows that they require both Q1 and Q2 P1 t1 Q1 Request edge t3 Q2 t2 P2 t4 Grant edge P1, P2: processes Q1, Q2: resources Georgia Institute of Technology

11 Background: Terms Grant deadlock (G-dl) A deadlock situation directly caused by a grant The same assumptions with the previous P1 P2 P3 P1 P2 P3 t1 t3 t2 t4 t5 Q1 Q2 Q3 Q1 Q2 Q3 Request edge Grant edge Assumption (iv): Priorities P1 > P2 > P Georgia Institute of Technology

12 Differentiation between R-dl and G-dl Reason Some actions can only be taken for either R-dl R or G-dl. G (E.g., G-dl G could have been avoided by granting Q2 to P3 instead of P2 in the previous G-dl G example.) P1 Q1 P1 P2 P3 Q2 P2 Q1 Q2 Q Georgia Institute of Technology

13 Why does deadlock occur? - Four Deadlock Conditions Properties of Resources Mutual Exclusion No simultaneous sharing of a resource No Preemption A resource can be released only by the process holding the resource. Behavior of Processes Hold and Wait A process may hold some resources while the process requests additional resources. Circular Wait A process must wait for unavailable resources to become available Georgia Institute of Technology

14 Background: Terms Single vs. Multiple Instance Resources Single instance resources A resource that can support one process at a time E.g., a printer Multiple instance resources A resource that can support a certain number of multiple processes simultaneously E.g., a counting semaphore associated with allocable memory Georgia Institute of Technology

15 Background: Terms Resource Allocation Graph (RAG) A Set of Nodes V = P U Q P i : processes, Q j : resources A Set of Edges E = (P( i Q j ) U ( U (Q j P i ) P 1 P 2 P 3 P 4 Request edge Grant edge Q 1 Q 2 Q 3 Q 4 Bipartite Graph Georgia Institute of Technology

16 Terms RAG and Corresponding Matrix Representation M Used in Deadlock Detection Unit (DDU) RAG Allocation matrix processes resources Georgia Institute of Technology

17 Terms RAG and Corresponding Matrix Representation M RAG request edges Allocation matrix grant edges Georgia Institute of Technology

18 Terms RAG and Corresponding Matrix Representation M Connect nodes Terminal nodes Terminal row Terminal column RAG Allocation matrix Incoming edge Outgoing edge Terminal edges Georgia Institute of Technology

19 Prior Work by Shiu, Tan and Mooney Deadlock Detection Hardware Unit (DDU) Matrix based parallel operation approach Terminal edge reduction technique to reveal cycles (i.e., deadlock) Terminal (i.e., removable) edge*: not related to deadlock Simple bit-wise Boolean operations Implementation easier Operation faster, O(min(m,n)) 2~3 orders of magnitude faster than software Novelty from previous algorithms Does NOT trace exact cycles Does NOT require linked lists P. Shiu, Y. Tan and V. Mooney, "A Novel Parallel Deadlock Detection Algorithm and Architecture," 9th International Workshop on Hardware/Software Codesign (CODES'01), pp , April P1 * Q1 P2 Q2 P3 Q Georgia Institute of Technology

20 Abstraction of DDU Check the reducibility of an allocation matrix Remove all terminal edges currently revealed at each step in matrix M If (either R s R s or G) in column i (terminal( column) remove all entries in column i If (either R s R s or G s) G in row j (terminal( row) Remove all entries in row j Iterate until (reducible) or empty Determine deadlock If empty (no edges), no deadlock If (empty), deadlock Terminal edges Iterations Georgia Institute of Technology Not empty Deadlock

21 Prior Work in Deadlock Avoidance Traditional Methods Require some knowledge of future requests Declare maximum claims (each process) Give a grant only if remaining in a safe state Advantages No deadlock No preemption Disadvantages Low resource utilization Worse for single unit resources Performance degradation Due to dynamic avoidance decision Practical issues long software run-time Georgia Institute of Technology

22 Prior Work in Deadlock Avoidance Dijkstra: : Banker s s Algorithm (1968) For a single multiple-instance instance resource Maximum claims strategy Habermann: : O(nm 2 ) (1969) For multiple-instance instance multiple resources Livelock problem Holt: O(mn) ) (1972) Solved livelock problem using wait-time time counters For general resource systems Belik (1990) Path matrix representation Resource allocation Changing an acyclic digraph while keeping it acyclic For multiple single-instance instance resources O(mn) ) in general, O(1) in the best case No prior work in hardware implementation of a deadlock avoidance approach Georgia Institute of Technology

23 P1 Q1 Outline Q2 P2 Motivation and Objective Background and Prior Work Proofs about Deadlock Detection Unit Deadlock Avoidance Unit Parallel Banker s s Algorithm Unit Integration into δ hardware/software RTOS framework Conclusion Georgia Institute of Technology

24 Proofs of the Correctness of and run-time complexity of DDU Why do proofs matter? Authenticity No false alarm To avoid any damages or liability To ensure timeliness in a real-time SoC Within a certain amount of time for a robot not to fall over in a deadlock * Additional details can be found in a journal submission and a technical report [3, 7] Georgia Institute of Technology

25 Proof of the Correctness of DDU Deadlock vs. Cycle Relation Deadlock Cycle(s) in an RAG Cycle(s) Deadlock P1 Q1 P1 P2 P3 Q2 P2 Q1 Q2 Q3 DDU detects deadlock iff there exists a cycle in an RAG Georgia Institute of Technology

26 Proof of the Correctness of DDU - Intuition behind proofs Remove edges in columns and rows with only G s or only R s Operations performed in parallel throughout the matrix at each iteration A cycle: a circular pairs of R-G edges in rows and in columns Step 0 Step 1 Step 2 Step 3 Step 4 Step 5 Completely reducible Iterations No deadlock Georgia Institute of Technology

27 Proof of the Run-time Complexity of DDU An upper bound on the number of edges in a path (not a cycle or RAG) = 2*min(m,n min(m,n) Due to the bipartite property DDU, implemented in hardware, completes its computation in at most 2*min(m,n min(m,n) - 3 steps O(min(m,n)) P1 P2 P3 P4 P5 P6 Q1 Q2 Q3 2*min(6,3)=6 * Additional details in a journal submission and a technical report [3, 7] Georgia Institute of Technology

28 P1 Q1 Outline Q2 P2 Motivation and Objective Background and Prior Work Proofs about Deadlock Detection Unit Deadlock Avoidance Unit Parallel Banker s s Algorithm Unit Integration into δ hardware/software RTOS framework Conclusion Georgia Institute of Technology

29 Deadlock Avoidance Unit (DAU) No declaration of maximum claims No restriction on resource usage Advantages Higher resource utilization Fast avoidance due to hardware implementation Disadvantages Somewhat unfairness on a special occasion When avoiding G-dl G (a lower priority process could proceed before a higher priority process, which would end up in deadlock) -- Similar concept to priority inheritance But, resulting in higher resource utilization Possibility of resource preemption When avoiding R-dlR Assumption: all resources single-instance instance Georgia Institute of Technology

30 Deadlock Avoidance Algorithm (DAA) An n event of a request Is the resource available? Y N Would cause R-dl? R Y N Resolve livelock as well as deadlock Grant it to the requester * No deadlock here Priority of requester > Priority of owner Y N Mark the request pending Mark the request pending Ask the current owner to release the resource Ask the requester to give up resource(s) return Georgia Institute of Technology

31 Deadlock Avoidance Algorithm (DAA) An n event of a release Any process is waiting? N Mark the resource available Y Granting it to the highest priority process causes G-dl? G Y Grant it to a process causing no deadlock after finding such a process Improve resource utilization N Grant it to the highest priority process waiting return Georgia Institute of Technology

32 Proof of the Correctness of DAA Proof with lemmas and theorems Theorem 1 (R-dl case) Denying the request in the case of R-dl results in livelock unless a process involved in the deadlock releases a resource involved in the deadlock Theorem 2 (G-dl case) For a given system, not currently deadlocked, where a grant of a resource occurs, there must exist at least one process to which the resource can be granted without deadlock Georgia Institute of Technology * Additional details in a technical report

33 Architecture of the DAU DDU Address decoder Address control (matrix) Start Cell access DAA Command registers Data Reset Logic Done Deadlock w/ FSM Status registers Georgia Institute of Technology DDU: Deadlock Detection Unit FSM: finite state machine

34 State Transition Diagram - DAA Logic FSM request available? n release y R-dl? y idle grant waiting? n n make pending find owner y R>O search next pending owner give up compare priorities temporary grant requester give up O>R y G-dl? grant FSM: finite state machine n Georgia Institute of Technology

35 DAU Experimentation - Target System-on-a-Chip Four MPC755 s Each CPU has 32KB I-Cache I and 32KB D-CacheD 100MHz external clock, 16MB shared memory HW SW RTOS Four resources Q1: Video Interface (VI) Q2: Inverse Discrete Cosine Transform (IDCT) Q3: Fast Fourier Transform (FFT) Q4: Network Interface (NI) Georgia Institute of Technology

36 DAU Experimentation - RTOS, Application, Environment Atalanta RTOS 0.3 By Sun, Blough and Mooney at Georgia Tech Each process requires two resources except P4 P1: processing a video stream (needs VI + IDCT) P2: separating/enhancing frames (needs IDCT + FFT) P3: extracting special images (needs FFT + VI) P4: transferring images (needs NI) One active process for each processing element (PE) Seamless CVE from Mentor Graphics Instruction accurate simulation VCS (Synopsys( Synopsys) ) and XRAY (Mentor) Georgia Institute of Technology

37 Experimental Results of DAU G-dl avoidance simulation: Two kinds DAU: Synopsys VCS runs compiled Verilog code DAA in software: MPC755 runs compiled C code in Seamless CVE Example application invokes deadlock avoidance 12 times P1 P2 P3 P1 P2 P3 t1 t3 t2 t4 t5 Q1 Q2 Q3 Q1 Q2 Q Georgia Institute of Technology

38 Experimental Results of DAU (cont d) G-dl avoidance simulation result Time line with resource usage Q 1 and Q and Q 2 P 1 t =801 1 t = Q 2 and Q and Q 3 P 2 t = t = t =24888 t 7 8 =34791 Q 2 and Q and Q 3 P 3 t = t =16809 t 6 6 =24885 bus clock cycles Georgia Institute of Technology

39 Experimental Results of DAU (cont d) G-dl avoidance simulation result Performance improvement 99% algorithm execution time reduction 37% reduction in an application execution time Method of Deadlock Avoidance Algorithm Exe. Time (cycles) Normalized Exe. Time Application Exe. Time (cycles) DAU Hardware 7 (average) 1X DAA in Software 2188 (average) 312X Georgia Institute of Technology

40 Experimental Results of DAU (cont d) R-dl avoidance simulation: Two kinds DAU: Synopsys VCS runs compiled Verilog code DAA in software: MPC755 runs compiled C code in Seamless CVE Example application invokes deadlock avoidance 14 times P1 P2 P3 t4 t1 t2 t3 P1 t6 P2 t5 P3 Q1 Q2 Q3 Q1 Q2 Q Georgia Institute of Technology

41 Experimental Results of DAU (cont d) R-dl avoidance simulation result Performance improvement 99% algorithm execution time reduction 44% reduction in an application execution time Method of Deadlock Avoidance Algorithm Exe. Time (cycles) Normalized Exe. Time Application Exe. Time (cycles) DAU Hardware 7.13 (average) 1X DAA in Software 2102 (average) 294X Georgia Institute of Technology

42 Synthesis Results of DAU Synopsys Design Compiler TSMC.25µm m technology library from Qualcore Logic 0.05% of the total SoC area with four PEs and memory Module Name DAU 5x5 7x7 10x10 15x15 20x20 MPSoC Total Area in terms of two-input NAND gates Million Clock period used: 4 ns Lines of Verilog HDL Code Georgia Institute of Technology TSMC: Taiwan Semiconductor Manufacturing Company PE: Processing Element

43 P1 Q1 Outline Q2 P2 Motivation and Objective Background and Prior Work Proofs about Deadlock Detection Unit Deadlock Avoidance Unit Parallel Banker s s Algorithm Unit Integration into δ hardware/software RTOS framework Conclusion Georgia Institute of Technology

44 Parallel Banker s Algorithm (PBA) Parallelized Version of the Banker s s Algorithm For multiple-instance instance resources Advantages Guarantee deadlock avoidance Support multiple instance resources Provide O(n) ) run-time complexity Reduced from the original O(mn 2 ) O(1) in the best case Disadvantages Require hardware Require maximum claim declaration May under-utilize utilize resources Georgia Institute of Technology

45 PBAU Architecture (3x3) Georgia Institute of Technology

46 Parallel Banker s Algorithm (PBA) An n event of a request Is the request valid? Y Are the resources available? N N Y Pretend allocation Safe check (next slide) Safe? Y Grant it N Undo alloc Deny the request Georgia Institute of Technology return

47 Parallel Banker s Algorithm (PBA) Safety check Work[j]:= ]:=Available[j]] for all j Finish[i] ] := false for all i Find all able-to to-finish processes i in parallel (i.e., Finish[i] ] == false and Need[i][j] Work[j] ] for all j) Does any such process still exist? N Decision Y For all such able-to to-finish processes i { Finish[i] ] := true Work[j] ] = Work[j] ] + Allocation[i][j] ] for all j } return Georgia Institute of Technology

48 Resource Allocation by PBA q 1 Initial state resources q 2 instances for resources available allocated p 1 for processes need p 2 allocated p 3 (Legend) Georgia Institute of Technology

49 Resource Allocation by PBA Current safe state q 1 resources q 2 instances for resources available allocated p 1 for processes need p 2 allocated p Georgia Institute of Technology

50 Resource Allocation by PBA Current safe state q 1 resources q 2 instances for resources available allocated p 1 for processes need p 2 allocated p Georgia Institute of Technology

51 Resource Allocation by PBA Next state, safe? q 1 resources q 2 instances for resources available allocated p 1 for processes need p 2 allocated p Georgia Institute of Technology

52 Resource Allocation by PBA instances q 1 resources q 2 for resources available Finish allocated p 1 p 2 for processes need allocated p Georgia Institute of Technology

53 Resource Allocation by PBA instances q 1 resources q 2 for resources available Finish allocated p 1 p 2 for processes need allocated p Georgia Institute of Technology

54 Resource Allocation by PBA instances q 1 resources q 2 for resources available Finish allocated p 1 p 2 for processes need allocated p Georgia Institute of Technology

55 Resource Allocation by PBA instances q 1 resources q 2 for resources available Finish allocated p 1 p 2 for processes need allocated p Georgia Institute of Technology

56 Resource Allocation by PBA instances q 1 resources q 2 for resources available Finish allocated p 1 p 2 for processes need allocated p 3 A safe sequence: p 2 p 1 p Georgia Institute of Technology

57 Resource Allocation by PBA instances q 1 resources q 2 for resources available Finish allocated p 1 p 2 for processes need allocated p 3 A safe sequence: p 2 p 1 p 3, 3 steps, i.e., O(n) Georgia Institute of Technology

58 Resource Allocation by PBA An example of O(1) run-time instances q 1 resources q 2 for resources available Finish allocated p 1 p 2 for processes need allocated p Georgia Institute of Technology

59 Resource Allocation by PBA An example of O(1) run-time instances q 1 resources q 2 for resources available Finish allocated p 1 p 2 for processes need allocated p 3 A safe sequence: any combination Georgia Institute of Technology

60 PBAU Experimentation - System and Application Five processors Four resources Q1: Multiple DSPs Q2: Hardware semaphores Q3: I/O buffers Q4: A memory allocator PBAU 5x5 A robotic application Five processes Requires multiple instances 22 times of service requests to PBAU Requests, releases and claim settings HW SW RTOS Georgia Institute of Technology

61 Experimental Results of PBAU Performance improvement 99% algorithm execution time reduction 19% reduction in an application execution time Method of Deadlock Avoidance Algorithm Exe. Time (cycles) Normalized Exe. Time Application Exe. Time (cycles) PBAU Hardware 3.32 (average) 1X BA in Software 5398 (average) 1625X Georgia Institute of Technology

62 Synthesis Results of PBAU Synopsys Design Compiler TSMC.25µm m technology library from Qualcore Logic 0.05% of the total SoC area with five PEs and memory All PBAUs able to handle up to 16 instances for each resource Module Name PBAU 5x5 8x8 10x10 15x15 20x20 MPSoC Georgia Institute of Technology Total Area in terms of two-input NAND gates Million Clock period used: 4 ns TSMC: Taiwan Semiconductor Manufacturing Company PE: Processing Element Lines of Verilog HDL Code

63 P1 Q1 Outline Q2 P2 Motivation and Objective Background and Prior Work Proofs about Deadlock Detection Unit Deadlock Avoidance Unit Parallel Banker s s Algorithm Unit Integration into the δ hardware/software RTOS framework Conclusion Georgia Institute of Technology

64 δ framework Hardware/Software RTOS/MPSoC Configuration Framework Enables automatic generation of different mixes of the HW/SW RTOS Can be generalized to instantiate additional HW or SW RTOS components Integrates parameterized IP Generators such as DDU, DAU and PBAU generators Designed by Mooney and Lee RTOS Components: designed by B. Akgul, P. Kuarchroen, J. Lee, K. Ryu, M. Shalan and E. Shin Georgia Institute of Technology

65 δ framework - Methodology δ Framework DDU User Input Hardware Description Library GUI Tool DAU PBAU Top.v User.h HW Compile HW Library Executable HW Compiled Hardware Library Modelsim Simulation in Seamless CVE Result and Feedback Makefile SW Compile Executable SW HW RTOS Info. SW RTOS Info. Application SW Library XRAY Georgia Institute of Technology

66 δ framework - Methodology GUI Bus: designed by K. Ryu SoCLC: designed by B.Akgul SoCDMMU: designed by M. Shalan Georgia Institute of Technology

67 δ framework - Methodology GUIs for a custom bus generation Georgia Institute of Technology

68 Deadlock IP generator GUI Georgia Institute of Technology

69 δ framework -Implementation Verilog top file generation example Start with PBAU description Generate instantiation code multiple instantiation code if needed (e.g., PEs) IP Library Desc PBAU ~~~ enddesc (i) Generate code clock clock_gen (SYSCLK); cpu_mpc750 cpu1 ( ); bpau pbau5x5 (addr, data, ); arbiter arb (br_bar, bg_bar ); Add wires and initial statements PEs 1,2,3, Memory 1,2, PBAU Clock Arbiter (iii) After Instantiation wire addr; wire data; wire br_bar; wire bg_bar; wire SYSCLK; initial begin end; (ii) Add wires and initial states Georgia Institute of Technology

70 Conclusion with Contribution Proofs of Deadlock Detection Unit (DDU) Correctness and run-time complexity Deadlock Avoidance Unit (DAU) Faster Deadlock Avoidance (312X) No prior knowledge about resource requirements No restrictions on resource usage Higher resource utilization Solution to livelock Parallel Banker s s Algorithm Unit (PBAU) Faster deadlock avoidance for multiple instance multiple resource systems (1600X) Small area (less than 0.1% in our example SoC) δ Hardware/Software RTOS partitioning framework With custom deadlock IP generator for a specific target Georgia Institute of Technology

71 Publications [1] ] J. Lee and V. Mooney An O(n) Parallel Banker s s Algorithm for System-on on-a-chip, Chip, submitted to Design, Automation and Test in Europe (DATE( DATE 05), under review. [2] ] J. Lee and V. Mooney Hardware/Software Partitioning of Operating Systems: Focus on Deadlock Detection and Avoidance, to be appeared in IEE Computer & Digital Techniques (IEE CDT), January [3] ] J. Lee and V. Mooney An O(min(m,n)) Parallel Deadlock Detection Algorithm, resubmitted to ACM Transactions on Design Automation of Electronic Systems (TODAES) on September 2004, under review. [4] ] J. Lee and V. Mooney A A Novel Deadlock k Avoidance Algorithm and Its Hardware Implementation, International Conference on Hardware/Software Codesign and System Synthesis (CODES 04),, pp , 205, September [5] J. Lee, V. Mooney, A. Daleby,, K. Ingstrom,, T. Klevin and L. Lindh, A A comparison of the RTU hardware RTOS with a Hardware/Software RTOS, Proceedings of the Asia South Pacific Design Automation Conference (ASPDAC( 2003), pp , 688, January Best Paper Award Candidate (one of 12 nominees; not selected for Best Paper). [6] J. Lee, K. Ryu and V. Mooney, A A framework for automatic generation of configuration files for a custom RTOS, Proceedings of the Engineering of Reconfigurable Systems and Algorithms (ERSA( 2002), pp , 37, June [7] ] J. Lee and V. Mooney An O(min(m,n)) Parallel Deadlock Detection Algorithm, Tech. Rep. GIT-CC CC-03-41, College of Computing, Georgia Institute of Technology, Atlanta, GA. September [8] ] B. Akgul,, J. Lee and V. Mooney, A System-on on-a-chip Lock Cache with Task Preemption Support, Proceedings of the International Conference on Compilers, Architecture and Synthesis for Embedded Systems (CASES( 2001), pp , 157, November Georgia Institute of Technology

72 Q & A Thank you! Georgia Institute of Technology

73 Deadlock Avoidance Algorithm (DAA) More about R-dl avoidance If f P1>P2 P1 Q2 Q1 P2 Ask P2 to release Q2 Q2 can be granted to P1 If f P2>P1 P1 Q2 Q1 P2 Ask P1 to release Q1 Q1 can be granted to P Georgia Institute of Technology

74 Proof of the Correctness of DDU Algorithm Correctness Not empty cycle(s) deadlock Empty no cycle(s) no deadlock Proof with 5 Lemmas 4 Theorems * Additional detail can be found in a journal submission and a technical report [3, 7] Georgia Institute of Technology

75 Proof of the Correctness of DDU Algorithm (cont d) 5 Lemmas Removing terminal edges will not alter any cycle If a RAG can be completely reduced, the system does not have a deadlock If no cycles in a RAG, the RAG can be completely reduced. A process that is making progress is not involved in deadlock If a system does not have a deadlock, all processes can make progress within a finite time Georgia Institute of Technology

76 Proof of the Correctness of DDU Algorithm (cont d) 4 Theorems If a RAG contains any cycle, the RAG cannot be completely reduced If a RAG cannot be completely reduced, the RAG contains at least a cycle A cycle is a necessary and sufficient condition for deadlock DDU Algorithm detects deadlock iff there exists a cycle in a RAG Georgia Institute of Technology

77 Proof of Run-Time Complexity of DDU Q: How many steps does DDU need to detect deadlock in parallel hardware? Proof with 2 Corollaries 1 Lemma 1 Theorem * Additional detail can be found in a journal submission and a technical report [3, 7] Georgia Institute of Technology

78 Proof of Run-Time Complexity of DDU (cont'd) 2 Corollaries The total number of nodes in the smallest possible cycle = 4 The number of edges in any path (not cycle) using all nodes in the smallest possible cycle = 3 P1 P2 P1 P2 Q1 Q2 Q1 Q Georgia Institute of Technology

79 Comparison: DDU and DAU Method of Deadlock Detection DDU DDU in software Detection Time (average cycles) Normalized Detection Time 1X 1408X Method of Deadlock Avoidance Hardware Software Avoidance Time (average cycles) Normalized Avoidance Time 1X 312X Georgia Institute of Technology