Integrated concurrency control protocol for hard real-time database systems

K.-W. Lam S.-L. Hung

Abstract: Real-time transactions must meet their deadlines in hard real-time database systems (RTDBS). To preserve data integrity, hard RTDBS require concurrency control protocols to synchronise transactions to access shared data. Transaction blocking enforced by concurrency control protocols leads to priority inversion problems which violate the principle of priority- based scheduling and degrade system schedulability. Unfortunately, this blocking time can be indefinitely long, which is unacceptable in hard real-time applications. An integrated scheduling and concurrency control protocol is proposed that allows a high priority transaction to pre-empt an uncommitted lower priority transaction while preventing the lower priority transaction from being restarted even in the face of data conflicts. The new protocol alleviates priority inversion problems by allowing more transaction schedules than other protocols.

1 Introduction

In real-time systems, tasks must be scheduled to meet their timing constraints. Timing constraints. usually in terms o f deadlines, of different tasks in real-time systems can be either hard, soft or nonexistent [I] . A hard-deadline task must be completed before its deadline at all times. Failure to meet a hard deadline can potentially result in a catastrophe. A deadline is considered to be soft if a task must be completed only most of the time. After missing its soft deadline, the task may still have some diminishing value to the system. With the advent of faster and cheaper hardware, real-time systems are used in newer application domains where automation is more reliable and cheaper. Typically, the applications of real-time systems are avionics systems, production control, robotics and defence systems.

Real-time systems are complex and some use database technology to support a task's access to shared data resources. These are called real-time database systems (RTDBS) [l]. RTDBS require concurrency control protocols to synchronise

0 IEE, 1997 IEE Proceedings online no. 19911224 Paper first received 4th April 1996 and in I-wised form 5th March 1997 The authors arc with the Department of Computer Science, City Univer- sity of Hogn Kong, 83 Tat Chee Avenue, Kowloon, Hong Kong

214

transactions to access shared data and to ensure both logical correctness of data and timing constraints of transactions. An important problem that arises in the context of priority-based scheduling in real-time systems is the effect of blocking caused by concurrency control protocols. To preserve data integrity, transactions are normally blocked if they access data in conflicting mode. Priority inversion occurs when a high priority transaction is blocked while a low priority transaction has locked on to a shared data item [2]. Priority inversion should be minimised as it degrades system schedulability. Unfortunately, this blocking time can be indefinitely long, which is unacceptable in real-time applications.

The goal of concurrency control protocols in hard RTDBS is not to reduce mean lateness or the number of late transactions, but to devise approaches that are amenable to preruntime characterisation of all blocking and overheads. Such characterisation is indispensable in the test of whether or not a transaction set meets its deadlines. A good concurreiicy control protocol must not only ensure strong correctness criteria of transac- tion executions, i.e. serialisability [3], but also provide a tight bound on transaction blocking.

To cope with the priority inversion problem, a number of concurrency control protocols based on priority inheritance [4-61 have been proposed. These protocols can provide a tight bound on the duration of transaction blocking of, at most, the duration of a single lower priority transaction. This is called a single- blocking property. Moreover, they are deadlock-free. With these properties, one can make possible the schedulability analysis of a transaction set and determine whether some of the transactions will miss their deadlines or not before the system actually executes the transaction set. While they can provide a bound on transaction blocking and schedulability analysis, one of their major weaknesses is that they allow only restrictive transaction schedules due to the conservative scheduling transactions needed to access the shared data.

In this paper, we propose an integrated scheduling and concurrency control protocol that allows a high priority transaction to pre-empt an uncommitted lower priority transaction and at the same time prevents the lower priority transaction from being restarted even in the face of data conflicts. The new protocol alleviates priority inversion problems by allowing more transaction schedules than other protocols.

IEE Psoc -Comput. Digit. Tech., Vol. 144, No. 4, July I997

2 Basic concept of the new protocol

In hard RTDBS, resources should ideally be allocated to higher priority transactions to expedite their execu- tion. However, for the integrity of shared data, transac- tions may have to be blocked by concurrency control protocols to resolve data conflicts. In some cases, higher priority transactions are able to pre-empt lower priority transactions where transactions are otherwise blocked unnecessarily in some protocols [6]. Erthancing the capability of high priority transactions to pre-empt lower priority transactions decreases transaction block- ing and increases system schedulability.

We examine the conditions under which a higher pri- ority transaction can pre-empt an uncommitted lower priority transaction under the update-in-workspace transaction model [3]. In this model, transactions defer their updates to the end of their executions. That is, before a transaction commits, it reads and updates data items only in its private workspace and then data items are written into the database only upon successful com- mit. Since the serialisation order among transactions will be fixed only at the commitment of transactions in this model, it provides greater flexibility in resolving data conflicts and in determimng the serialisation order. Some previous work on real-time concurrency control protocols has adopted this model [7-91.

We assume that a high priority transaction pre-empt- ing a lower priority transaction cannot entail restarting a lower priority transaction subsequently. Restarting a transaction means the transaction is started again from the beginning. Thus, restarting transactions to resolve data conflicts complicates system schedulability analy- sis [lo]. To simplify our analysis, we assume that a write operation is always preceded by a read operation for the same data item. This means that the write set of a transaction is a subset of its read set and that there are no blind writes [3]. In priority-based scheduling, a lower priority transaction T, may block a higher prior- ity transaction TH only when it has accessed a data item before TH does and in conflicting mode. Suppose TL has accessed a data item x. We consider two possi- ble cases of data conflicts between TL and TH and ana- lyse whether T, is allowed to pre-empt TL under the requirement of not restarting transactions.

Let R,(x) and W,(x) denote transaction T, reads and writes of data item x, respectively; RS, and WSi denote the set of data items read and written by transaction Ti, respectively, and DR, denote the current set of data items that transaction Ti has already read. Case 1: W,(x) - RH(x) conflict I n this case, T, can pre-empt TL provided that TH commits before TL. I f T, commits after TH pre-empts T,, then TI, writing x will invalidate the value of x that TH has read. In that case, T H has to be restarted and this is forbidden. To ensure that T, commits before TL, we must make sure that TH does not have any other data conflicts with TL, in which case T,, will be blocked, either directly or indirectly. Case 2 : RL(x) - W,(x) conflict In this case, T, cannot pre-empt T[, and is blocked. If TH were allowed to pre-empt TL, to write x, and to commit before TL, then TL would have to be restarted in order to maintain data integrity. In fact, the seriali- sation order between T , and TH has to be TL -+ T H in this case.

IEE Pvoc.-Cornput. Digit. Tech, Vol 144, Ao. 4, July I997

In the WL(x> - RH(x) conflict case, TL’s pre-emption entails the guarantee that TH must commit before TL as the serialisation order has been constrained to be TH +

TL. In the RL(x)-WI1(x) conflict case, TH is precluded from pre-empting TL and writing x. Hence, it is observed that a necessary condition to allow T H to pre- empt TL in the WL(x) - RH(x) conflict case is WS, n DRL = El. In other words, TL will not block TH due to R , ( x ) ~~ WH(x> conflicts after TH pre-empts T,. Note that in other concurrency control protocols using two- phase locking [4-61, TH is blocked in the WL(x) - RH(x) conflict case, reducing the allowable transaction sched- ules.

Although a higher priority transaction TH may pre- empt a lower priority transaction T, in the update-in- workspace model in the WL(x) - RH(x) conflict case, if TH is allowed to pre-empt TL in an uncontrolled way, an undesirable impact on the system may follow. For example, TL has written a data item x and an interme- diate priority transaction T, wants to read x. If we allow T, to pre-empt T, and read x, when a high pri- ority transaction TH wants to write x, TH will be blocked by both TM and TL. This violates the single- blocking property. In the worst case, a deadlock will be formed. Therefore, we have to incorporate a blocking mechanism to block lower priority transactions earlier so that high priority transaction blocking will be strictly bounded to a single lower priority transaction only. However, the blocking mechanism cannot be so conservative as to restrict many transaction execution schedules.

3 Integrated concurrency control protocol

Based on the foregoing analysis, we propose an inte- grated concurrency control protocol that allows a high priority transaction to pre-empt an uncommitted lower priority transaction while the lower priority transaction will be prevented from being restarted even in the face of data conflicts. Before we describe the new protocol we make some assumptions about it.

We assume that the system has a single processor and all transactions in the system operate under the update-in-workspace model with a memory-resident database and are periodic transactions with rate monotonic priority assignment [ll]. That is. a transac- tion with a shorter period is assigned a higher priority and the deadline of a transaction is at the end of its period. The priorities of transactions are of a total order. This initial priority of a transaction is called the original priority. Transactions are assigned to the proc- essor based on their current running priorities which are initially equal to their original priorities. If a trans- action blocks a higher priority transaction, its running priority will inherit that of the higher priority transac- tion. The transaction with the highest running priority ready to execute is scheduled to run on the processor. Before a transaction can read (or write) data item x, it must first obtain the read (or write) lock on the data item x. All the locks will be released only after the commitment of a transaction. This transaction model is suitable for the tracking applications such as air-traffic control where data items (tracks) are updated periodi- cally via periodic scanning. Tracks of interests will be read by operators periodically in the form of periodi- cally updated displays at operator consoles. For tiinely response, tracks of airplanes are typically kept in the main memory.

215

Data items are assigned three different priority ceil- ings. The write priority ceiling of a data item x, WPC(x), is the priority of the highest priority transac- tion that may write x. The absolute priority ceiling of x, APC(x), is the priority of the highest priority trans- action that may read or write x. The priority ceiling function of x, PCF(x), is dynamically determined at runtime. When a transaction write-locks x, PCF(x) is set equal to APC(x). When a transaction read-locks x, PCF(x) is set equal to WPC(x). The main purpose of assigning priority ceilings to data items is to block lower priority transactions earlier for the single-block- ing property. We will discuss the use of priority ceilings later in this Section.

Let Pi denote the priority of transaction Ti and H- PCF denote the highest PCF(x) among all the data items locked by transactions other than TI. Let T,, ..., T, denote an ordered set of transactions listed in descending order of priority, with TI having the highest priority, and CRL denote the set of data items that are currently read-locked by transactions other than T,. Now, we describe the mechanism of the new protocol which consists of two parts: a concurrency control algorithm and an inheritance algorithm. While the con- currency control algorithm controls the grants of locks on data items to transactions, the inheritance algorithm implements the priority inheritance mechanism. Trans- acton Ti is allowed to read-lock or write-lock a data item x if one of the concurrency control rules (i.e. CC1 and CC2) is true. (Concurrency control algorithm) CCl T,'s priority is higher than the highest priority

ceiling function of data items locked by other transactions, i.e. PI > H-PCF. The priority of Ti is equal to the highest priority ceiling function of data items locked by other transactions and the write set of Ti does not intersect with the set of data items currently read-locked by transactions other than Ti, i.e. PI = H-PCFand WSi rl CRL = 0.

CC2

(Inheritance algorithm) I1 If transaction Ti is denied a read-lock or write-lock

on data item x, transaction Ti that holds the lock for the data item inherits Pi, i.e. q s running prior- ity is now equal to Pi.

I2 When Ti releases the locks on its data items after it has completed its execution, returns to its origi- nal priority if it has inhented a higher priority.

With the use of the subtle mechanism of priority ceil- ing assignment to data items, we need not explicitly check for data conflicts under the new protocol. For CCl, when a data item x is write-locked by a transac- tion Ti, H-PCF is equal to APC(x). Hence, no other transaction can read-lock x including the highest prior- ity transaction that may write 01- read x. On the other hand, when x is read-locked, H-PCF is equal to WPC(x). Hence, no other transaction can write-lock x. Only the transactions with a priority higher than H- P C F will be allowed to read-lock x because two read operations on the same data item are nonconflicting operations.

For CC2, 71 will be the highest priority transaction that may write or read x. Suppose that x is currently being read-locked by r J , Ti can only pre-empt TJ when Tj wants to read-lock x. If Ti wants to write-lock x, the

216

condition, WS, n CRL = 0, forbids T, from write- locking x. On the other hand, suppose that x is being write-locked by a currently executing transaction q; ithis implies that x is also read-locked by T / . In this case, Ti can pre-empt Ti only when Ti wants to read- llock x. Since only the highest priority transaction that imay access x can lock on to a data item by satisfnng CC2, we have one and only one transaction having a llock on x before the highest priority transaction read- !locks x when CC2 is true.

4 Execution example

:Suppose that we have three transactions T,, T, and T3 :In descending order of priority. Without loss of gener- iality, we assume the period of T, to be 5 time units. The data items accessed by the three transactions are :shown as follows: Ti: R(x) R b ) T,: R(x) W(X) R b ) WCy) T3: R(z) W(Z) .write priority ceilings of x, y and z: WPC(x) = P,,

-read priority ceilings of x, y and z: APC(x) = P,, W P C b ) = P,, WPC(z) = P3

.APC(y) = P,, APC(2) = P,

T1 Ea .fiZEzi Ea h n * h

time Fig. 1 Tiansac tion Jtheilule under the new protocol

'The execution of the three transactions under the new ;protocol is shown in Fig. 1. We now describe the exe- cution of the three transactions as follows. At time 0, T, is initiated and then read-locks data item z. At time 1, T2 is initiated and attempts to read-lock data item x. :Since H-PCF = P3 and CCI is true, T, is allowed to :read-lock x and pre-empt T,. T, is also allowed to .write-lock s at time 2 because CCI is true. At time 3, T, is initiated and attempts to read-lock x. Since now .H-PCF = P,, CC1 is not true. However, since CC2 is true, T, is allowed to read-lock x and pre-empts T2. T , :IS allowed to read-lock y subsequently at time 4. At time 5, TI finishes its execution. T, is awoken to con- tinue its execution and can read-lock and write-lock y ;at times 6 and 7, respectively, since H-PCF = P, after T, finishes its execution. At time 8, T, arrives in its inext period. Since CC2 is also true, T, is allowed to read-lock x and y again and finishes its execution at ;time 10. At time 10, T2 is awoken again and finishes its execution at time 11. Then, T3 is awoken to resume its execution. At time 12, T, attempts to write-lock z. :Since there is no other transaction executing, i.e. H- PCF = 0 at that moment, T, is allowed to write-lock z. .4t time 13, T, arrives again. Similarly, TI can read- llock x and y and finishes at time 15. At time 15, T, is awoken again and finishes its execution at time 16.

For comparison, we also show the execution of the three transactions under the read/write priority ceiling ]protocol (RW-PCP) in Fig. 2. We will not describe the execution under RW-PCP. Interested readers are ref- ered to [6] . It can be observed that under RW-PCP, the worst-case effective blocking time of T, by the lower

IEE Proc.-Comput Digit Tech., Vol. 144, No. 4, July 1997

priority transaction T2 is 4 time units. In the worst case, TI may be blocked after T2 finishes for 2 time units of execution until T, finishes for 6 time units of execution. The first instance of TI is blocked by T2 from time 3 to 7 and T, misses its deadline at time 8. In contrast, under the new protocol, the worst case blocking time of TI is eliminated because T, is allowed to gain access to x and y although x and y are being write-locked by T2. That is, T, does not encounter blocking in this transaction set. Thus, the new protocol can allow more transaction schedules than RW-PCP, thus improving system schedulability.

attempt* missing to read-

/Lock x Jdead'lne

5 Properties and correctness

In this Section we prove that the new protocol has two important properties (single blocking and deadlock- free) which enable schedulability analysis of a transac- tion set. Then, we prove the correctness of the new pro- tocol, i.e. show that it ensures serialisable executions of transactions. For the correctness of the new protocol, we prove that all histories, H, produced by the new protocol are serialisable. That is, H cannot have: a cycle in the serialisation graph, SG(H) [3].

Lemma I : Suppose that transaction T, read-locks or write-locks a data item x by satisfying either CC1 or CC2 of the concurrency control rules. Then, th.ere will be no lower priority transaction that can block Ti until 7; completes its execution. Prooj: Consider the following two situations: (1) If CCI is true, Pi > H-PCF. Thus, no transaction with priority equal to (including Ti) or higher than Ti will lock the data items currently locked by the lower priority transactions. Hence, no lower priority transac- tion can block Ti or any other higher priority transac- tion, and inherit a priority higher than Pi. Moreover, no following transaction with priority lower than Pi can pre-empt Ti. Thus, Ti cannot be blocked by lower priority transactions before Ti completes its execution. (2) If CC2 is true, Pi = H-PCF. Thus, no transaction with priority higher than Pi will lock the data item x already locked by the currently executing transactions. Thus, no currently executmg transaction can inherit a priority higher than Pi unless the currently executing transactions can lock additional data items. However, the pre-empted transaction can resume its execution before Ti completes its execution only if Ti is blocked by one of the currently executing transactions. How- ever, this will not happen as CC2 ensures that WS, n CRL = 0. That is, transaction T, will not write-lock a data item which is already read-locked by the currently executing transactions. In other words, T, will not be

IEE Pror.-Com~iu~. Digit Tech., Vol. 144, No. 4, July 1997

blocked by the currently executing transactions. Thus, the lemma follows.

Lemma 2: The new protocol prevents transitive block- ing. Prooj Suppose that transitive blocking occurs in the new protocol. For some i 2 2 let Ti block Ti-, and let Ti_, block Ti-2, i.e. Ti-, is transitively blocked by T,. By the definition of the new protocol, to block Ti--,, Ti must have read-write conflicts with Ti-, at time to. Similarly to block Ti.~2, T,, must have read-write con- flicts with Ti-2 at time t l . At time t l , let the data items with the highest priority ceiling locked by Ti and Ti-l be x and y , respectively. Since Ti..l is allowed to lock data item y when Ti has already locked x, one of the concurrency control rules must have been true. If any one of concurrency control rules is true, by lemma 1, Ti will not be able to block Ti-,, which contradicts our assumption. The lemma follows.

Theorem 3: Deadlock is impossible in the new protocol. Proofi A deadlock can be formed only by a cycle of transactions waiting for one another. Let the n transac- tions involved in this cycle be TI, ..., T, with Tl having the highest priority. By lemma 2, the number of trans- actions in the blocking cycle can only be 2, i.e. n = 2. Since a transaction having no data item locked cannot contribute to the deadlock, each of the n transactions must have locked some data items. Without loss of generality, suppose that T2 was pre-empted by TI, which then locks some data item. For TI to lock some data item, one of the concurrency control rules must have been true. However, if either of CCl or CC2 was true, by lemma 1, T2 cannot block T I S Hence, a dead- lock cannot occur. The theorem follows.

Theorem 4: A transaction T, can be blocked by at most a single lower priority transaction during its exe- cution under the new protocol. Proof When TH arrives and is blocked, by lemma 2, there must be only one transaction TL blocking it. By theorem 3, there will be no deadlock. Hence, after TL completes its executions at some time t l and releases all its locks, TL will be pre-empted by TH. Since TL has no data item locked, it cannot inherit a priority higher than its original priority. Since there exists no other transaction that can block TH, and no following lower priority transactions can block TH. The lemma follows.

Lemma 5: If a transaction successfully commits, it will not have write--read conflicts with the currently run- ning transactions. Proofi Suppose TH has write-read conflicts with a cur- rently running transaction T,. The condition, WSH, f' DR, 8 @, is sufficient to prevent TH from pre-empting TL. In this case, TH is blocked and must commit after T, does, which contradicts our assumption. Hence, the lemma follows.

Theorem 6: If N is a history produced by the new pro- tocol, then H is serialisable. Proof: Suppose that - Ti 0' # i) is an edge of SG(H). Then, Tj and are committed in H and there are con- flicting operations /3/(x) and n(x) such that Dj(x) pre- cedes yi(x). For the same edge that Ti commits before Ti accesses x, a conflict is not considered to occur. By the definition of conflicting operations, pj(x) and n(x) are either Rj(x) and Wi(x) or Wi(x) and Ri(x). By

211

lemma 5 , fll(x) and y,(x) should be Rj(x) and W,(x). respectively. We claim that the commitment of pre- cedes that of Ti. Suppose T, was committed first. At the ume T, commits, Wi(x) must have been processed by the scheduler; hence Wi(x) precedes R,(.u) and conflicts with it. Tj is currently executing. Thus, Ti cannot com- mit since it violates lemma 5. It is contrary to our assumption that Ti is committed before T, in H. There- fore, it can be shown that if - T, is in SG(H), T, must commit before Ti in H. By induction, if a cycle exists in SG(H), every transaction on that cycle would have to commit before itself which is an absurdity. Thus, SG(H) is acyclic and H is serialisable.

6 System schedulability

With the single-blocking and deadlock-free properties, we can perform the schedulability analysis of a transac- tion set using rate-monotonic priority assignment [ 1 11 and the new protocol. For the schedulability condition, it has been proved in [6] that a set of y1 periodic trans- actions using rate-monotonic priority assignment under RW-PCP can always meet their deadlines if the follow- ing conditions are satisfied:

where E,, D , and B, are the execution time. the period and the worst-case blocking time of transaction T,. respectively. It can be observed that the above schedu- lability conditions are also applicable to the new proto- col. To have a better schedulability condition for a transaction set depends on the value of B,. The smaller the value of Bi is, the better the schedulability condi- tion. We devise a procedure to determine the value of Bi as rollows:

Let TBS, denote the set of lower priority transac- tions that may block a transaction TH and is called the blocking transaction set of T14. It can be observed that TL E TBS, if one of the following blocking conditions is true: (1) TL may read-lock a data item x whose write priority ceiling is higher than that of T,, i.e. PL < PH and TL reads x and P, s WPC(x) or (2) TL may write-lock a data item x whose read priority ceiling is higher than that of T,,, i.e. PL < P, and TL writes x and P, < APC(x) or (3) T, may write-lock a data item x whose read priority ceiling is equal to that of T, and the write set of T, intersect with the read set of TL, i.e.

PL < PH and TL writes J: and P H = A P C ( z )

Therefore, the worst-case blocking time of T,: B, = max (ELI for all T, E TBSH.

7 Conclusions

and wslI n R S ~ , # 0

Hard real-time database systems must provide a guar- antee of satisfying the stringent timing requirements on

the executions of real-time transactions. However, exe- cutions of real-time transactions require concurrency control protocols to preserve data integrity when many transactions concurrently access shared data. Transac- tions may be blocked due to the data integrity require- ments, resulting in priority inversion problems. This unpredictability of transaction executions is unaccepta- ble in some mission-critical applications. Thus, a good concurrency control protocol must provide a predicta- ble response even though transactions may be blocked in their execution.

Some concurrency control protocols have been pro- posed to resolve the priority inversion problem and provide a worst-case schedulability analysis. They avoid deadlocks and guarantee that a transaction is blocked by at most one lower priority transaction. However, they are too conservative in scheduling trans- actions which access shared data. As a result, they allow only restrictive transaction schedules, thus reduc- ing the schedulability condition of a transaction set.

In this paper, we propose an integrated concurrency control protocol that allows a high priority transaction to pre-empt an uncommitted lower priority transaction while preventing the lower priority transaction from being restarted even in the face of data conflicts. The new protocol can allow more transaction schedules than other protocols. Moreover, we have shown that it maintains single-blocking and deadlock-free properties and have proved its correctness. We have also pre- sented better schedulability conditions for systems using the new protocol.

8

1

2

3

4

5

6

7

8

9

10

11

References

YU. P.S.. WU, K.L., LIN. K.J., and SON, S.H.: ‘On real-time databases: concurrency control and scheduling’, Pime. IEEE, 1994. 82, ( I ) , pp. 140-IS7 RAJKUMAR, R.: ‘Synchronization in real-time systems: a prior- ity inheritance approach’ (Kluwer Academic, Dordrecht, 1991) BERNSTEIN, P.A., HADZILACOS, V., and GOODMAN, N.: ’Concurrencp control and recovery in database systems’ (Addi- son-Wesley, Reading, MA, 1987) CHEN. M., and LIN, K.J.: ‘Dynamic priority ceilings: a concur- relic) control protocol for real-time systems‘, Red-Time Syst., 1990. 2. (4). 325-346 SHA. L., RAJKUMAR, R., and LEHOCZKY, J.P.: ‘Priority inheritance protocols: an approach to real-time synchronization’, (EEE Twns. Cornput., 1990, 39, (9). pp. 1175-1 185 SHA. L.. RAJKUMAR, R., SON, S.H., and CHANG, C.H.: ‘A real-time locking protocol’, IEEE Trims. Conzput., 1991, 40, (7),

HARTTSA. J.R.. CAREY, M.J.. and LIVNY. M.: ‘Data access pp. 793-799

scheduling ’in firm real-time database systems’, Reul-tinze Syst., 1992. 4. ( 3 ) . pp. 203-243 LAM. K. W., LAM, K.Y ., and HUNG, S.L.: ‘Real-time optimis- tic concurrency control protocol with dynamic adjustment of seri- alization order’. Proceedings of IEEE Real-Time Technology and Application Symposium (RTAS ‘95), Chicago, USA, 1995, pp. 174-179 LEE. J.. and SON, S.H.: ‘Using dynamic adjustment of serializa- tion order for real-time database systems’. Proceedings of 14th IEEE Real-time Systems Symposium. 1993. pp. 66-75 SHU. L.. and YOUNG, M.: ‘A mixed lockingiabort protocol for hard real-time systems’. Proceedings ol‘ the 11 th lEEE Workshop on Real-time opemting systenu und softwuve, Washington, 1994, pp. 102-105 LIU, C.L.. and LAYLAND, J.W.: ‘Scheduling algorithms for multi-programming in a hard-real-time environment’, J. ACM, 1973, 20. ( I ) , pp. 46-61

218 IEE PUJC -Comput Digit. Tech, VO/ 144, hro 4, July I997