Philip P. Macri

dblp:09/3242 · DBLP profile ↗
← Back
1ranked-venue papers
1as first author
0since 2021 · last 1976
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Databases, data management, data science and information retrieval · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Databases, data mining, and information retrieval
1 paper
Transaction processing and concurrency control · 77% Data models and query languages · 23%

Topics — the 2 heaviest of 2, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Transaction processing and concurrency control
deadlock detection and resolution
0.011976
Deadlock Detection and Resolution in a CODASYL Based Data Management System · SIGMOD Conference 1976
Data models and query languages › data modeling
network data model
0.011976
Deadlock Detection and Resolution in a CODASYL Based Data Management System · SIGMOD Conference 1976

Methods — techniques the papers use, named apart from their topics

lock-based concurrency control · 0.0
YearPublicationVenuePosition
1976 Deadlock Detection and Resolution in a CODASYL Based Data Management System
abstract
In a multi-task computer system many different types of situations may occur in which productive computation may be brought to a standstill. One of these is deadlock or "deadly embrace". Some of the earliest investigation into this problem was undertaken by Dijkstra [1], Habermann [2] and Havender [3]. A detailed presentation of the deadlock problem and its ramifications may be found in [1, 2, 3, 4, 5].Because deadlock is so costly, modern computer system software is designed so that deadlock is either impossible [6, 7] or the probability of its occurrence is minimized at the system level. For example, the INGRES data base management system [7] accomplishes deadlock prevention without compromising data base integrity. Unfortunately, the CODASYL design [8] does not preclude the possibility of deadlock. It leaves the burden of minimizing the probability of its occurrence to the design of the application. There are two parts to the application design: the database design and the software design. Judicious design of both parts can sometimes minimize deadlock. However, deadlock cannot be prevented in all cases. Therefore, deadlock detection and resolution mechanisms are essential for operation in a multi-thread environment. Initially, the CODASYL based data management system employed (DMS 1100 [11]) had very simple deadlock detection and resolution mechanisms. The deadlock detection mechanism was based on the sufficient condition that deadlock exists when the number of transactions registered with the data management system equals the number of transactions locked out of resources. A least number of page alterations criterion was used by the deadlock resolution mechanism to resolve deadlock. That is, the transaction with the least number of altered pages was rolled back in an attempt to resolve deadlock. If this failed to resolve deadlock, the roll back selection process was repeated until deadlock was resolved. It was discovered that these mechanisms seriously degraded throughput on our system and a new approach was needed. This paper contains a description of the deadlock detection algorithm and the deadlock resolution algorithm which was implemented to overcome this defficiency. The former detects deadlock and the latter resolves deadlock in a manner consistent with maximum system throughput.In order to establish a common framework for discussion, the concepts of lock out and deadlock will be defined before proceeding.
Philip P. Macri
SIGMOD Conference1