1 / 12

Deadlock Detection for Distributed Process Networks

Deadlock Detection for Distributed Process Networks. Alex G. Olson & Brian L. Evans The University of Texas at Austin. Motivation for Formal Models. Applications may require higher input/output and computational rates than one CPU can handle Exploit parallelism for high performance

edith
Download Presentation

Deadlock Detection for Distributed Process Networks

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. Deadlock Detection for Distributed Process Networks Alex G. Olson & Brian L. Evans The University of Texas at Austin ICASSP 2005

  2. Motivation for Formal Models • Applications may require higher input/output and computational rates than one CPU can handle • Exploit parallelism for high performance • Parallel (one machine) or distributed (many machines) • Pitfalls of parallel/distributed programming • Synchronization, shared memory, and deadlock • Debugging concurrent code on many processors • Formal models have provable properties • Determinacy: programs are correct by construction • Validation: only debug each component separately • Scalability: faster execution with more CPUs ICASSP 2005

  3. Applications Design Space Exploration [Vissers & Wolf, 1999] Image Processing [Webb et al., 1999] ICASSP 2005

  4. Process Networks [Kahn, 1974] • Concurrently executing processes • Communicate only over one-wayunbounded channels (FIFO queues) • Read one input port at a time • Node execution suspended until enough data available • Data that has been read is dequeued from channel • Samples (tokens) flow along arcs • Samples have value but not time information • Flow of (untimed) data drives computation • Determinate execution • Any scheduling algorithm that obeys above rules will produce same history of tokens on arcs ICASSP 2005

  5. Bounding Size of PN Queues • Bounded Scheduling [Parks & Lee, 1995] • Write to a full queue suspends node execution • On global deadlock, resize smallest queue • Favors incomplete bounded execution (non-determinate) • Computational PN [Allen & Evans, 2000] • Processes may consume fewer tokens than read • All memory allocation can be handled by queues • Bounded Scheduling [Geilen & Basten, 2003] • Show local deadlock may not lead to global deadlock Artificial deadlock Deadlock detection required for bounded communication, but no framework detects local deadlock ICASSP 2005

  6. Deadlock Detection Algorithm • Mitchell & Merritt’s algorithm[1984] • Detects local and global deadlocks • Exactly one process detects deadlock • Simplifies deadlock resolution • Pair of labels (numbers) used for deadlock detection • Deadlock detected when a label makes a “round-trip” among set of blocked processes ICASSP 2005

  7. 3,3 1,1 1,4 1,3 4,2 1,2 1,4 2,1 1,4 1,1 1,3 1,2 1,4 2,1 3,3 4,2 Public (count, pid) Private(count, pid) Mitchell-Merritt Example Write to B Read from C BUSY BUSY B A B A Blocking Step Initial State D C D C Read from A BUSY BUSY Arrows indicate waiting.Artificial deadlock without feedback. ICASSP 2005

  8. 4,2 4,2 4,2 4,2 2,1 4,2 2,1 4,2 4,2 1,4 4,2 1,4 3,3 1,4 3,3 1,4 Public Label Private Label Transmit Step Deadlock Detected Mitchell-Merritt Example B A B A D C D C ICASSP 2005

  9. Implementation • Distributed framework for Computational Process Networks • TCP sockets for communication • Transmit and receive queues (zero-copy) • C++, POSIX threads http://www.ece.utexas.edu/~bevans/projects/pn ICASSP 2005

  10. Execution Performance Overhead <1μs per read/write ICASSP 2005

  11. Execution Performance Overhead <1μs per read/write ICASSP 2005

  12. Conclusion • Formal models simplify parallel design, implementation, and debugging • Communication in PN model follows “Single-Resource” semantics • Mitchell-Merritt algorithm applicable to non-distributed, parallel, and distributed PN’s • Can be used to implement bounded-memory scheduling algorithms ICASSP 2005

More Related