IEEE TRANSACTIONS ON COMPUTERS, VOL. C-36, NO. 4, APRIL 1987 443

Extending Multiversion Time-Stamping Protocolsto Exploit Type Information

MAURICE HERLIHY, MEMBER, IEEE

Abstract-Atomic transactions are a widely accepted approachto implementing and reasoning about fault-tolerant distributedprograms. This paper shows how multiversion time-stampingprotocols for atomicity can be extended to induce fewer delaysand restarts by exploiting semantic information about objectssuch as queues, directories, or counters. This technique relies onstatic preanalysis of conflicts between operations, and incurs noadditioiwal runtime overhead. This technique is deadlock-free,and it is applicable to objects of arbitrary type.

Index Terms-Abstract data types, atomicity, concurrencycontrol, fault tolerance, multiple versions, serializability,

I. INTRODUCTION

T HE data items managed by distributed applications are1 often subject to consistency constraints that must be

preserved in the presence of concurrency and failures. Theseconstraints apply not only to individual data items, but also todistributed sets of data. For example, a distributed bankingsystem might be subject to the constraint that the booksbalance: mnoney is neither created nor dXestroyed, only transfer-red from one ledger to another. A widely accepted approach tothis problem is to ensure that activities are atomic: that is,indivisible and recoverable. Indivisible means that activitiesappear to execute in a serial order [10], and recoverablemeans that an activity either succeeds completely or has noeffect. Such atomic activities are called transactions.Many techniques have been proposed for implementing

atomicity in distributed systems (for a survey, see [1]). Thispaper considers one such mechanism, a multiversion time-stamping protocol due to Reed [13], and shows how it can beextended to induce fewer delays and restarts by exploitingsemantic information about the object. While conventionalapproaches consider only untyped objects providing READ andWRITE operations, our approach explicitly considers typedobjects such'as queues, directories, or counters, that provide aricher set of operations. We propose a systematic techniquefor preanalyzing conflicts between operations, a simple andefficient mechanism for detecting these conflicts at runtime,and we give proofs of correctness and optimality. This

Manuscript received November 12, 1986. This work was supported by theDefense Advanced Research Projects Agency (DOD), ARPA Order 4976, andmonitored by the Air Force Avionics Laboratory under Contract F33615-84-K-1520. The views and conclusions contained in this document are those ofthe author and should not be interpreted as representing the official policies,either expressed or implipd, of the Defense Advanced Research ProjectsAgency or the U.S. Government.The author is with the Department of Computer Science, Carnegie-Mellon

University, Pittsburgh, PA 15213.IEEE Log Number 8613056,

protocol is readily integrated with quorum consensus replica-tion, and it can also be used as the basis for optimisticconcurrency control. Like most multiversion time-stampingprotocols, ours is deadlock-free.

II. RELATED WORXTwo-phase locking [2] is a well-known alternative to

multiversion time-stamping protocols. A direct comparison ofthe two approaches is difficult, since each permits interleav-ings the other does not. Locking is subject to deadlocks, whiletime-stamping is not. Time-stamping, however, may besubject to livelock, since unfortunate combinations of eventsmay cause a transaction to be repeatedly aborted and restarted.Multiversion time-stamping protocols appear to provide bettersupport for long, read-only transactions.

Time-stamping protocols are incompatible with two-phaselocking; the two protocols cannot be used together in the samesystem because they may impose incompatible serializationorders on transactions at different objects. Weihl [16] hasdeveloped analytic techniques for characterizing when atomic-ity mechanisms are compatible. The technique proposed heresatisfies a property called static atomicity, and is compatiblewith Reed's protocol.

Papadimitriou and Kanellakis [11] have studied the effect onconcurrency of restricting the number of versions retained bymultiversion timestamping schemes, and the author [5] hasstudied how various atomicity mechanisms affect the availabil-ity of replicated data.

III. AssumPriONS AND DEFINITIONS

A distributed system consists of multiple computers (calledsites) that communicate through a network. Distributedsystems are typically subject to site crashes and communica-tion link failures. A crash renders a site's data temporarily orpermanently inaccessible, while a communication link failurecauses messages to be'lost. A failure is detected when a sitethat has sent a message fails to receive a response after acertain duration. The absence of a response may indicate thatthe original message was lost, that the reply was lost, that therecipient has crashed, or simply that the recipient is slow torespond.A transaction that completes successfully is said to commit,

otherwise it aborts. A transaction that has neither committednor aborted is active. We rely on standard commitmentprotocols (e.g., [41, [14]) to ensure that a transaction eithercommits at all sites or aborts at all sites, and we rely onstandard techniques to recover from crashes [15].

0018-9340/87/0400-0443$01.00 © 1987 IEEE

IEEE TRANSACTIONS ON COMPUTERS, VOL. C-36, NO. 4, APRIL 1987

The basic containers for data are called objects. Each objecthas a type, which defines a set of possible states and a set ofprimitive operations that provide the only means to create andmanipulate objects of that type. For example, a FIFO queue

might be represented by an object of type Queue providing thefollowing operations. Enq places an item at the end of thequeue:

Enq Operation(i: Item)

and Deq returns the item at the head of the queue:

Deq = Operation() Returns(Item).

Deq is partial: it is undefined when the queue is empty. Atransaction invoking a partial operation is blocked until theoperation can return legally.

IV. INFORMAL OVERVIEW

This section gives an informal description of our technique.A formal description appears in Section V. We begin with a

simplified review of Reed's scheme [13] as adapted for theSwallow repository [12]. For brevity, we consider only single-level transactions, and we assume that no transaction writes an

object more than once.

When a transaction is created, it is issued a logicaltimestamp called its pseudotime. Transactions will be serial-izable in pseudotime order. An object is represented as a

sequence of versions, each labeled with a pseudotime.Versions associated with active transactions are called possi-bilities. Each object also keeps track of last-read, the latestpseudotime of a transaction to read the object.A transaction reads an object in the following steps.1) Select the version with the latest pseudotime preceding

the reader's.2) If that version is a possibility (i.e., the writer has not yet

committed), then delay the reader until the writer commits or

aborts, and restart the read.3) Advance last-read to the maximum of its current value

and the reader's pseudotime.4) Return the version to the reader.The reader must be delayed in Step 2) because the value to

be read is ambiguous.A transaction writes an object in the following steps.1) If the writer's pseudotime precedes last-read, then the

write is refused, and the writer is aborted and restarted with a

later pseudotime.2) Create a new version tagged with the writer's

pseudotime.The writer must be restarted in Step, 1) because it might

invalidate a value already read by another transaction. Thisprotocol is deadlock-free because no transaction ever waits fora transaction with a later pseudotime, thus cycles of depen-dence cannot arise.The limitations of this protocol can be illustrated by

considering the implementation of a FIFO queue. Because Enqand Deq would each be implemented as a READ followed by a

WRITE, this scheme permits no concurrency at all. Let A and Bbe transactions such that A's pseudotime precedes B's. If Ainvokes any operation before B, then B will be delayed, and if

B invokes any operation before A, then A will be aborted andrestarted. We will show that these constraints are stronger thannecessary, and propose an alternative scheme that permitsconsiderably more concurrency.

First, we introduce some terminology. An operationexecution is written op(args*)/term(res*) where op is anoperation name, args* denotes a sequence of argument values,term is a termination condition, and res* is a sequence ofresults. We use "Ok" for normal termination. The operationname and argument values constitute the invocation, and thetermination condition and result values constitute the re-sponse.An object is not represented as a sequence of versions;

instead it is represented as a sequence of operations called ahistory (see Fig. 3). To execute an operation, a transactiontentatively inserts the new operation in the history, in aposition determined by the transaction's pseudotime. If thetransaction commits, the operation become permanent, other-wise it is discarded. Synchronization is based on a predefinedconflict relation between pairs of operations. Each operationhas an associated ratchet lock, which ensures that notransaction's results are invalidated by a later transaction withan earlier pseudotime, as well as an associated possibilitylock, which ensures that a transaction is delayed if it dependsonMan operation executed by an uncommitted transaction. Anoperation's ratchet lock is the latest pseudotime of a transac-tion that executed that operation, and its possibility lock is theset of active transactions that have executed that operation.A transaction A executes an operation in the following

steps.1) When the object receives the invocation, it chooses a

response after assembling the subhistory of operations exe-cuted by committed transactions whose pseudotimes precedeA's.

2) Letp be the new operation, and letp conflict with q. A isdelayed while any transaction with an earlier pseudotime holdsa possibility lock for q. IfA is delayed, the operation must berestarted at Step 1), since the new state may produce adifferent response.

3) If q conflicts with p, and the ratchet lock for q exceedsA's pseudotime, then A is aborted and restarted with a laterpseudotime.

4) Otherwise, A is granted a possibility lock for p, p'sratchet lock is advanced to the maximum of its current valueand A 's pseudotime, and the object returns the response to A.

Reed's protocol can be viewed as a special case of ours,where versions correspond to WRITE operations, last-read isthe ratchet lock for READ, and possibilities are possibility locksfor WRITE. Because READ operations do not affect the results oflater operations, they do not need possibility locks, nor do theyneed to be recorded. Because WRITE operations cannot beinvalidated by later operations, they do not need ratchet locks.The extent to which this typed scheme induces fewer delays

and restarts than the untyped scheme depends on the nature ofconflicts. A formal characterization of conflicts is givenbelow; for now we rely on an informal definition: an operationp conflicts with an operation q if p can be invalidated byinserting q earlier in a history. For example, two valid but

AAA

HERLIHY: EXTENDING MULTIVERSION TIMESTAMPING PROTOCOLS

|Enq lDeqEnqDeq Conflict Conflict

Fig. 1. First conflict relation for queue.

=Enq DeqEnq Conflict

Dq Conflict

Fig. 2. Second conflict relation for queue.

incomparable conflict relations for the FIFO Queue data typeare shown in Figs. 1 and 2. In the first relation, Enq operationsconflict with no other operations, but Deq operations conflictwith all other operations. Here, any number of transactionscan execute concurrent Enq operations, but a transaction witha later pseudotime that attempts to execute a Deq will bedelayed. In the second relation, Enq operations conflict withone another, and Deq operations conflict with one another, butEnq operations do not conflict with Deq operations, and vice-versa. Here, one transaction may enqueue items while a

transaction with a later pseudotime dequeues other items, as

long as there are committed items to dequeue. In both cases, a

dequeueing transaction never interferes with a enqueueingtransaction with a later pseudotime.

V. FORMAL MODEL

This section presents formal definitions and correctnessarguments.

A. Histories and Schedules

In the absence of failures and concurrency, an object's stateis modeled by a sequence of operations called a history. Forexample, a history for a FIFO Queue is shown in Fig. 3. Aspecification for an object is the set of permissible historiesfor that object. For example, the specification for a Queueconsists of histories in which items are dequeued in first-in-first-out order. A legal history is one that is included in theobject's specification.

In the presence of failures and concurrency, an object's stateis given by a schedule, which is a sequence of operationexecutions,, transaction begins, transaction commits, andtransaction aborts. To keep track of interleaving, a transac-tion identifier is associated with each step in a schedule. Forexample, a schedule for a FIFO Queue appears in Fig. 4 whereA and B are transaction identifiers. The ordering of operationsin a schedule reflects the order in which the object returnedresponses, not necessarily the order in which it receivedinvocations.We assume schedules satisfy the following well-formed-

ness conditions..1) No transaction executes an operation before it has

begun.2) No transaction executes an operation after it has commit-

ted.3) No transaction both commits and aborts.4) No transaction begins, commits, or aborts more than

once.

Enq(x)/Ok()Enq(y)/Ok()Deq(/Ok(x)

Fig. 3. A history for a FIFO queue object.

Begin AEnq(x)/Ok() A

Begin BEnq(y)/Ok BCommit A

Deq(/Ok(x) B

Fig. 4. A schedule for a FIFO queue object.

(Serial) histories and (concurrent) schedules are related bythe notion of atomicity. Let -+ denote a total order oncommitted and active transactions, and let H be a schedule.The serialization of H in the order -+ is the history hconstructed by reordering the operations inH so that ifA -* Bthe subsequence of operations associated with A precedes thesubsequence of operations associated with B. H is serializablein the order -+ if h is a legal (serial) history. H is serializableif it is serializable in some order. H is atomic if thesubschedule associated with committed transactions is serial-izable, and it is on-line atomic if committing any set of activetransactions yields an atomic schedule.

The schedules produced by the concurrency control mecha-nism proposed in this paper are static atomic [16]: transac-tions are serialized in the order of their begin operations, asobserved by a system of logical clocks [9]. Weihl has shownthat static atomicity is a local property: if each object in asystem encompassing multiple objects is static atomic, thesystem as a whole is atomic.

B. Conflict and Serial Dependence

This section gives a formal characterization of what itmeans for operations to conflict. Let > be a relation betweenpairs of operations, and let h be a legal history. A legalsubhistory g of h is >-closed if whenever it contains anoperationp it also contains every earlier operation q of h suchthat p > q. A subhistory g is a > -view of h for p if g is > -closed, and if g contains every q of h such that p > q.Informally, > is a serial dependence relation if whenever anoperation is legal for a > -view, it is legal for the completehistory. More precisely, let " " denote concatenation.

Definition 1: A relation > is a serial dependence relationif for all operations p and all legal histories h and g such that gis a > -view of h for p, g -p is legal implies that h p is legal.We show below that our technique is static atomic if and

only if the conflict relation between operations is a serialdependence relation. Of primary interest are minimal rela-tions having the property that no smaller relation is also aserial dependence relation. The reader can verify that therelations shown in Figs. 1 and 2 are minimal serial dependencerelations. It is easy to show that failure to commute is a serialdependence relation, but as illustrated by the FIFO queueexample, it is not necessarily minimal.The notion of serial dependence arises in other contexts as

well. For example, serial dependence has also been used forvalidation in optimistic concurrency control mechanisms [7].

445

IEEE TRANSACTIONS ON COMPUTERS, VOL. C-36, NO. 4, APRIL 1987

For quorum consensus replication [6], [8] constraints onavailability and concurrency are governed by a slightlymodified form of serial dependence, defined between invoca-tions and operations rather than between operations.

C. The Automaton Model

An object is modeled by an automaton that accepts certainschedules. The automaton's state is defined using the follow-ing primitive domains: TRANS iS the set of transaction identifi-ers, op is the set of operations, PSEUDOTIME is a totally orderedset of pseudotimes. The derived domain HISTORY is the set ofsequences of operations. X -- Y denotes the set of partialmaps from X to Y.An object has the following state components:

Intentions: TRANS -+ HISTORY

Ratchet: op -+ PSEUDOTIMEPossibility: op -+ 2TRANSClock: PSEUDOTIME

Active: 2TRANSCommitted: 2TRANSAborted: 2TRANSBegin: TRANS PSEUDOTIME.

Intentions(A) is the history of operations executed bytransaction A, initially none. Ratchet(p) is the value for p'sratchet lock, initially - oo. Possibility(p) is the set of activetransactions that hold a possibility lock for p, initially none.The Clock component models a system of logical clocks, andBegin(A) is the pseudotime assigned to A. Active, Commit-ted, and Aborted keep track of the transactions that areactive, committed, and aborted; each is initially empty.

Let S ' Active U Committed be a set of transactions {Ao,. , AJ} such that Begin(A,_ 1) < Begin(A,). Define State(S)

to be the history constructed by concatenating the intentionslists of the transactions in S in pseudotime order

State(S) = Intentions(Ao) * ... . Intentions(An)If A is a transaction, define

Before(A) = { B E Committed U ActiveABegin(B) < Begin(A )}

View(A ) = State(Before(A) n Committed) * Intentions(A).

Before(A) is the set of committed and active transactions withpseudotimes earlier than A's, and View(A) is the committedstate "observed" by A.

Each transaction has a precondition and a postcondition. Inpostconditions, primed component names denote new values,and unprimed names denote old values. To reduce thecomplexity of the preconditions, we assume all schedules arewell-formed. When A begins execution:

Post: Clock' > ClockBegin(A)' = ClockActive' = Active U {A }.

The clock is advanced, A is assigned a pseudotime, and A isnoted as active.

For A to execute operation p:

Pre: If q > p, then Ratchet(q) < Begin(A).If p > q, then (Before(A) n Possibility(q)) -{A}= 0.View(A) -p is legal.

Post: Intentions'(A) = Intentions(A) -pRatchet '(p) = max(Ratchet(p), Begin(A))Possibility'(p) = Possibility(p) U {A }.

There must be no conflicting ratchet or possibility locks, andthe operation must appear to be legal. The new operation isappended to the intentions list, and the operation's ratchet andpossibility locks are set.

For A to commit:

Post: Active' = Active - {A}.Committed' = Committed U {A}.Forp in Intentions(A), Possibility '(p) = Possi-bility(p) - {A }.

For A to abort:

Post: Active' = Active - {A }.Aborted' = Aborted U {A}.For p in Intentions(A), Possibility '(p) = Possi-bility(p) - {A }.

D. The Proof

We use the following two lemmas, which are provedelsewhere [7].Lemma 2: If > is a serial dependence relation, g and h

histories, and q an operation such that g- q and g* h are legal,and there is no p in h such that p > q, then g * q- h is legal.Lemma 3: If > is not a serial dependence relation, then

there exist a history h and an operationp such that h has a > -view g ofp missing exactly one operation, g -p is legal, buth p is not.The following invariant is an immediate consequence of the

rules for granting ratchet and possibility locks.Lemma 4: If Begin(A) < Begin(B), and A is active, then

no operation executed by B conflicts with any operationexecuted by A.

Proof: By a simple inductive argument. The propertyholds initially, so we show that it is preserved by eachtransition. Suppose p conflicts with q. If A has executed q,then B is prevented from executing p by the conflictingpossibility lock for q. IfB has executedp, thenA is preventedfrom executing q by the conflicting ratchet lock for p.We are now ready for the basic correctness result.Theorem 5: If the conflict relation is a serial dependence

relation, then every schedule accepted by the automaton is on-line static atomic.

Proof: The automaton is on-line static atomic if State(S)is a legal history for every S such that Committed C S C

446

HERLIHY: EXTENDING MULTIVERSION TIMESTAMPING PROTOCOLS

Active U Committed. The proof is by induction on the lengthof the accepted schedule. The base case, where the schedule isempty, is trivial. Assume as the induction hypothesis that theautomaton has accepted an on-line static atomic schedule. Wenow show that the next transition preserves on-line staticatomicity. Begin, commit, and abort events are immediate.The nontrivial case is when A executes an operation p. Pick anS that includes A, let hr h2 = State(S), and h1 p h2 =

State'(S), the state following the transition. h1 h2 is legal bythe induction hypothesis. View(A) is a > -view of hi for p(Lemma 4). Because the conflict relation is a serial depen-dence relation, h1Ip is a legal history. Moreover, no operationin h2 conflicts with p (Lemma 4), thus hl p h2 is legal(Lemma 2).Our scheme is optimal in the sense that no conflict relation

that is not a serial dependence relation suffices to ensure staticatomicity.

Theorem 6: Any automaton whose conflict relation is not a

serial dependence relation will accept a schedule that is not on-

line static atomic.Proof: Assuming > is not a serial dependence relation,

there exist an operation p and legal histories g and h such thatg is a > -view of h forp missing exactly one operation q, g-p

is legal, but h p is not (Lemma 3). Let g = a c and h =

a pq c. Let A, B, and C be transactions such that Begin(A) <Begin(B) < Begin(C). Transaction A executes a and com-

mits. C then executes c p, and B executes q. If S = {A, B,C}, State(S) is the illegal history a q c'p = h p.

VI. REMARKS

A practical difficulty with all multiversion protocols is theapparent need to keep a potentially unlimited volume of data.In Reed's protocol, one would keep a complete history ofversions, and in ours, one would keep a complete history ofthe object's operations. Reed suggests that although this datamight be useful as an audit trail, in practice one could discardsufficiently old versions, rejecting transactions that attempt toread or write with very old pseudotimes. Our scheme can beoptimized in a similar way: a prefix of the object's history can

be periodically compacted into a single version, and transac-tions with older pseudotimes are rejected. For example, a

queue can be represented by a single, compact version (i.e., a

list of the elements present in the queue) followed by a shortsequence of Enq and Deq operations, which are treated as a

differentialfile [15]. Other optimizations are straightforward:there is no need to create entries or possibility locks foroperations that do not modify the object's state, and there is noneed for ratchet locks for operations that return no informa-tion.Our protocol is readily integrated with quorum consensus

replication [3], [8]. A replicated object is an object whosestate is stored redundantly at multiple sites. Replicated objectsare implemented by two kinds of modules: repositories andfront-ends. Repositories provide long-term storage for theobject's state, while front-ends carry out operations forclients. A client executes an operation by sending theinvocation to a front-end. The front-end merges the data froman initial quorum of repositories, performs a local computa-

tion, and records the response at a final quorum of reposito-ries. A quorum for an operation is any set of sites thatincludes both an initial and a final quorum for that operation.Each operation's availability is determined by its set ofquorums, thus constraints on quorum assignment determinethe range of availability properties realizable by replication.

Because state information for replicated objects is distrib-uted, it is convenient to define conflicts between invocationsand events rather than between pairs of events. Each reposi-tory keeps a set of ratchet and possibility locks, and thereplicated object will be on-line static atomic if and only if theintersection of the conflict relation with the quorum intersec-tion relation must be an (invocation/event) serial dependencerelation. (In practice, they would be identical.) This require-ment ensures that any conflict will be detected at the nonemptyintersection of two quorums. A similar protocol in which theserialization order is determined dynamically is described indetail elsewhere [6].

Techniques proposed elsewhere [7] could be adapted totransform our protocol into a type-specific optimistic proto-col, in which transactions execute without synchronization,relying on commit-time validation to ensure serializability.Such optimistic protocols would preserve static atomicity, thusthey could be used in conjunction with static atomic pessimis-tic protocols.

This paper has proposed a technique that extends multiver-sion timestamping protocols to exploit type-specific propertiesof data objects to induce fewer delays and restarts thanconventional techniques employing a simple model of read/write conflicts. The problem of identifying a correct andminimal set of conflicts for an object is shown to be equivalentto the algebraic problem of identifying a minimal serialdependency relation for the data type. This technique relies onstatic preanalysis of conflicts between operations, and incursno additional runtime overhead.

REFERENCES

[1] P. A. Bernstein and N. Goodman, "Concurrency control in distributeddatabase systems," ACM Comput. Surv., vol. 13, pp. 185-222, June1981.

[2] K. P. Eswaran, J. N. Gray, R. A. Lorie, and I. L. Traiger, "Thenotion of consistency and predicate locks in a database system,"Commun. Ass. Comput. Mach., vol. 19, pp. 624-633, Nov. 1976.

[3] D. K. Gifford, "Weighted voting for replicated data," in Proc.Seventh Symp. Operat. Syst. Principles, ACM SIGOPS, Dec. 1979.

[4] J. Gray, "Notes on database operating systems," in Lecture Notes inComputer Science 60. Berlin: Springer-Verlag, 1978, pp. 393-481.

[5] M. P. Herlihy, "Comparing how atomicity mechanisms supportreplication," in Proc. Fourth ACM SIGACT-SIGOPS Symp.Principles Distrib. Comput., Aug. 1985.

[6] , "Availability versus atomicity: Concurrency control for repli-cated data," Dep. Comput. Sci., Carnegie-Mellon Univ., Pittsburgh,PA, Tech. Rep. CMU-CS-85-108, Feb. 1985.

[7] , "Optimistic concurrency control for abstract data types," inProc. Fifth ACM SIGACT-SIGOPS Symp. Principles Distrib.Comput., Aug. 1986, pp. 206-217.

[8] , "A quorum-consensus replication method for abstract datatypes," ACM Trans. Comput. Syst., vol. 4, Feb. 1986.

[9] L. Lamport, "Time, clocks, and the ordering of events in a distributedsystem," Commun. Ass. Comput. Mach., vol. 21, pp. 558-565, July1978.

[10] C. H. Papadimitriou, "The serializability of concurrent databaseupdates," J. Ass. Comput. Mach., vol. 26, pp. 631-653, Oct. 1979.

[11] C. H. Papadimitriou and P. Kanellakis, "On concurrency control by

447

IEEE TRANSACTIONS ON COMPUTERS, VOL. C-36, NO. 4, APRIL 1987

multiple versions," ACM Trans. Database Syst., vol. 9, pp. 89-99,Mar. 1984.

[12] D. P. Reed and L. Svobodova, "SWALLOW: A distributed datastorage system for a local network," in Proc. Int. Workshop LocalNetworks, Aug. 1980.

[131 D. P. Reed, "Implementing atomic actions on decentralized data,"ACM Trans. Comput. Syst., vol. 1, pp. 3-23, Feb. 1983.

[14] M. D. Skeen, "Crash recovery in a distributed database system,"Ph.D. dissertation, Univ. California, Berkeley, May 1982.

[15] J. S. M. Verhofstad, "Recovery techniques for database systems,"ACM Comput. Surv., vol. 10, pp. 167-196, June 1978.

[161 W. E. Weihl, "Data-dependent concurrency control and recovery," inProc. 2nd Ann. Symp. Principles Distrib. Comput., Aug. 1983.

Maurke Herlihy (S'82-M'84) received the A.B.degree in mathematics from Harvard University,Cambridge, MA, and the M.S. and the Ph.D.degrees in computer science from the MassachusettsInstitute of Technology, Cambridge, MA.

In 1984 he joined the Department of ComputerScience at Carnegie-Mellon University, Pittsburgh,PA, where he is now an Assistant Professor. Hisresearch interests include algorithms for replicationand concurrency control, as well as formal andinformal aspects of programming language supportfor reliable distributed computation.

448