Deadlock is an increasingly pressing concern as the multicore revolution forces parallel programming upon the average programmer. Existing approaches to deadlock impose onerous burdens on developers, entail high runtime performance overheads, or offer no help for unmodified legacy code. Gadara automates dynamic deadlock avoidance for conventional multithreaded programs. It employs whole-program static analysis to model programs, and Discrete Control Theory to synthesize lightweight, decentralized, highly concurrent logic that controls them at runtime. Gadara is safe, and can be applied to legacy code with modest programmer effort. Gadara is efficient because it performs expensive deadlock-avoidance computations offline rather than online. We have implemented Gadara for C/Pthreads programs. In benchmark tests, Gadara successfully avoids injected deadlock faults, imposes negligible to modest performance overheads (at most 18%), and outperforms a software transactional memory system. Tests on a real application show that Gadara identifies and avoids both previously known and unknown deadlocks while adding performance overheads ranging from negligible to 10%. 1

Abstract not found

Real-time mechanisms are important for supporting user interfaces, multi-media, and network processing on workstations. Current operating systems provide such real-time mechanisms. However workstations do not yet fully exploit such strong real-time properties and have only recently begun to partially use them for user interfaces, multimedia and network processing. In real-time environments, priority inversion is a well known phenomenon in which lower priority tasks block higher priority tasks because of semaphore blocking. It has been realised more recently that priority inversion is a serious problem when a real-time system uses task synchronisations for sharing resources. In order to solve the priority inversion problem, the priority inheritance protocol was invented about 20 years ago. The priority inheritance protocol was finally exploited in the standardisation of IEEE POSIX. Our primary goal in the design of new real-time synchronisation algorithms will be as follows: 1. The bl...

this article, we survey the resource management problem in computer systems by reviewing the principles, techniques, and tools involved in handling and avoiding deadlocks; we also propose a new method for handling deadlock in distributed databases, closing with some case studies on the resource management problem in large computer systems. Annotated references to works cited and a comprehensive bibliography of supplementary materials are provided.

iono For SIM 2 the reduction is one and a half times as great. MEASUI< SIM 1 EXP. C-1 SIM 2 EXP. C-2 Number of Times 2RD and 2WD Executed for CIO 13119 13422 15756 Mean CPM Service Time for LPP's CPM Time Spent Servicing LPP's from CIO for 2RD and 2WD (seconds) 0 CPM Time Saved by Having 2RD, 2WD, & CIO as One Overlay (secohds) 0 0 15678 .932 ms .932 ms 1.018 ms 1.018 ms 12.227 16.039 0 Experiment C - CIO-2RD-2WD Overlay 12.509 15.960 CPM Time Saved MEASU RE SIM 1 EXP. C-1 SIM 2 EXP. C-2 Central Memory .90 .89 .91 90 Degree of Multiprogramming 12.7 12.5 .3 9.4 per second 14.56 14.59 16.70 16.46 Experiment C - CIO-2WD-2RD Overlay 5.3.3 ummarz Comb. ining ClO, 2RD and 2WD results in some performance im- provement. Many overlays are quite small and other combinations might be considered. As the improvement was slight and CIO repre- sents such a large fraction of PP requests, little further improve- ment, however, seems likely. 5.4 Experiment D - All PP Overlays on

form a region with no exit. We might call such states S-states for Sisyphus who no matter how long he worked could never rest. Notice that deadlock states are just a special case of S-states in which a set of knotted processes have no non-e transitions. To put it another way if the first condition in the definition of "wait for" was changed so that the blocked processes could make non-e transitions but just could not reach a final state then S-states would be those in which a set of processes formed a knot. 4.5 Analyzing a System for Deadlock Analyzing a system for potential deadlock will involve generating some or all of a list R of the reachable system states. How much of R must be generated depends in part on the starting point of the analysis. Ideally one would observe a reachable state D in which two or more processes were blocked and then determine whether or not the blocked processes formed a knot. If no deadlock state D is suspected or if we are not sure it is re