Technical Report
CMU/SEI-89-TR-018
ESD-89-TR-026
A Real-Time Locking Protocol
Lui Sha
Ragunathan Rajkumar
Sang Son
Chun-Hyon Chang
April 1989
A Real-Time Locking Protocol
AB
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, Pennsylvania 15213
Technical Report
CMU/SEI-89-TR-018
ESD-89-TR-026
April 1989
Lui Sha
Real-Time Scheduling in Ada Project
Ragunathan Rajkumar
Carnegie Mellon University
Sang Son
University of Virginia
Chun-Hyon Chang
Kon Kuk University, Seoul, Korea
Unlimited distribution subject to the copyright.
This report was prepared for the SEI Joint Program Office HQ ESC/AXS
5 Eglin Street
Hanscom AFB, MA 01731-2116
The ideas and findings in this report should not be construed as an official DoD position. It is
published in the interest of scientific and technical information exchange.
FOR THE COMMANDER
(signature on file)
Thomas R. Miller, Lt Col, USAF, SEI Joint Program Office
This work is sponsored by the U.S. Department of Defense.
Copyright 1989 by Carnegie Mellon University.
Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and
\‘No Warranty\’ statements are included with all reproductions and derivative works. Requests for permission to reproduce this document or to
prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent.
NO WARRANTY
THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN \‘AS-IS\’ BASIS.
CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER
INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTIBILITY, EXCLUSIVITY, OR RESULTS
OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH
RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.
This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 with Carnegie Mellon University for the
operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a
royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit
others to do so, for government purposes pursuant to the copyright license under the clause at 52.227-7013.
This document is available through Asset Source for Software Engineering Technology (ASSET) / 1350 Earl L. Core Road ; P.O. Box 3305 /
Morgantown, West Virginia 26505 / Phone: (304) 284-9000 / Fax: (304) 284-9001 / e-mail: sei@asset.com / WWW:
http://www.asset.com/sei.html
Copies of this document are available through the National Technical Information Service (NTIS). For information on ordering, please contact
NTIS directly: National Technical Information Service / U.S. Department of Commerce / Springfield, VA 22161. Phone: (703) 487-4600.
This document is also available through the Defense Technical Information Center (DTIC). DTIC provides acess to and transfer of scientific and
technical information for DoD personnel, DoD contractors and potential con tractors, and other U.S. Government agency personnel and their
contractors. To obtain a copy, please contact DTIC directly: Defense Technical Information Center / 8725 John J. Kingman Road / Suite 0944 /
Ft. Belvoir, VA 22060-6218. Phone: 1-800-225-3842 or 703-767-8222.
1
Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.
CMU/SEI-89-TR-18 1
A Real-Time
Locking Protocol
Abstract: When a database system is used in a real-time application, the concur-
rency control protocol must satisfy not only the consistency of shared data but
also the timing constraints of the application. In this paper, we examine a priority-
driven two-phase lock protocol called the read- or write-priority ceiling protocol.
We show that this protocol is free of deadlock, and in addition a high-priority trans-
action can be blocked by lower priority transactions for at most the duration of a
single embedded transaction. We then evaluate system performance experimen-
tally.
1. Introduction
In a real-time database context, concurrency control protocols must not only maintain the
consistency constraints of the database but also satisfy the timing requirements of the trans-
actions accessing the database.
Both concurrency control [2, 3, 4, 5, 7, 16, 17, 18, 20, 21, 23, 26] and real-time scheduling
algorithms [10, 11, 13, 14, 15, 19, 22, 27] are active areas of research in their own right. It
may seem that the development of a real-time locking protocol is a simple matter of combin-
ing priority scheduling with a locking protocol. For example, we may require each trans-
action to use a well-known concurrency protocol such as the two-phase lock protocol [6] and
assign priorities to transactions according to some well-known scheduling algorithms such
as the earliest deadline algorithm [19]. Next, we process transactions in priority order. Un-
fortunately, such an approach may lead to unbounded priority inversion, in which a high-
priority task would wait for lower priority tasks for an indefinite period of time.
Example 1: Suppose T
1
, T
2
, and T
3
are three transactions arranged in descending order of
priority, with T
1
having the highest priority. Assume that transaction T
1
and T
3
share the
same data object O. Suppose that at time
t
1
transaction T
3
obtains a write-lock on O.
During the execution of T
3
, the high-priority task T
1
arrives and attempts to read-lock the
object O. Transaction T
1
will be blocked, since O is already write-locked. We would expect
that T
1
, being the highest priority transaction, will be blocked no longer than the time for T
3
to complete and unlock O. However, the duration of blocking may, in fact, be unbounded.
This is because transaction T
3
can be preempted by the intermediate-priority transaction T
2
that does not need to access O. The preemption of T
3
, and hence the blocking of T
1
, will
continue until T
2
and any other pending intermediate-priority level transactions are com-
pleted.
The blocking duration in Example 1 can be arbitrarily long. This situation can be partially
remedied if transactions are not allowed to be preempted; however, this solution is only ap-
propriate for very short transactions, because it creates unnecessary blocking. For instance,