Real-Time Database Systems:
Concepts and Design
Saud A. Aldarmi
Department of Computer Science
The University of York
Abstract
This qualifying dissertation is intended to review the state-of-the-art of Real-Time Database Systems under a
uniprocessor and centralized environments. Due to the heterogeneity of the issues, the large amounts of
infor-mation, and space limitation, we limit our presentation to the most important issues to the overall design, con-struction, and advancement of Real-Time Database Systems. Such topics are believed to include Transaction
Scheduling, Admission Control, Memory Management, and Disk Scheduling. Furthermore, Transaction
Scheduling consists of Concurrency Control Protocols, Conflict Resolution Protocols, and Deadlocks. Out of these issues, the most emphasis is placed on Concurrency Control and Conflict Resolution protocols due to their severe role on the overall systems performance. Other important issues that were not included in our presentation include Fault Tolerance and Failure Recovery, Predictability, and most important of all,
Mini-mizing Transaction Support; i.e., Relaxing Atomicity and Serializability. Various solutions to many of the
in-cluded topics are listed in chronological order along with their advantages, disadvantages, and limitations. While we took the liberty to debate some solutions, we list the debates of other researchers as well. The pres-entation concludes with the identification of five research areas, all of which are believed to be very important to the advancement of Real-Time Database Systems.
C
ontents
I
ntroduction
i1
Fundamentals in Real-Time Systems
1.1. Introduction … … … 1
1.2. System Models and Timing … … … 2
1.3. Scheduling … … … 4
1.3.1. Priority Based Scheduling … … … 5
1.4. Synchronization … … … 9
1.4.1. Priority Inheritance … … … 10
1.4.2. Priority Ceiling … … … 10
1.5. Overload … … … 11
2
Overview of Real-Time Database Systems
2.1. Introduction … … … 142.2. The Concept of Transactions and Serializability … … … … … … 15
2.3. Time-Critical Systems vs. Database Requirements … … … … … 18
2.4. Real-Time Database System Model … … … 20
2.5. Scheduling Real-Time Database Transactions … … … 22
2.5.1. Concurrency Control … … … 23 2.5.2. Conflict Resolution … … … 23 2.5.3. Deadlocks … … … 25 2.6. Admission Control … … … 25 2.7. Memory Management … … … 29 2.8. Disk Scheduling … … … 32
3
Concurrency Control
3.1. Introduction … … … 38
3.2. Locking Concurrency Control … … … 38
3.2.1. Synchronizing RTDB Transactions in Locking-based Protocols … … … 39
3.3. Optimistic Concurrency Control … … … 43
3.4. Speculative Concurrency Control … … … 47
3.5. Multiversion Concurrency Control … … … 49
3.6. Dynamic Adjustment of Serialization Order … … … 50
Introduction
In general, data in a real-time system is managed on individual basis by every task within the system. However, with the advancement of technology, many applications are requiring large amounts of information to be handled and managed in a timely manner. Thus, a substantial number of real-time applications are be-coming more data-intensive. Such lager amounts of information had produced an interdependency relationship among real-time applications. Therefore, in various application domains, data can no longer be treated and managed on individual basis, rather it is becoming a vital resource requiring an efficient data management mechanism. Meanwhile, database management systems are designed around such a concept; that is, with the sole goal of managing data as a resource. Hence, the principles and techniques of transaction management in Database Management Systems need to be applied to real-time applications for efficient storage and manipula-tion of informamanipula-tion.
In an attempt to achieve the advantages of both systems, real-time and database, continuous efforts are di-rected towards the integration of the two technologies. Such an integration of the two technologies resulted in combined systems known as Real-Time Database Systems. Real-Time Database Systems emerged with the publication of a special issue in the ACM SIGMOD Record in March 1988. Today, many applications require such systems, i.e., information retrieval systems, airline reservation systems, stock market, banking, aircraft and spacecraft control, robotics, factory automation, and computer-integrated manufacturing, and the list is vast.
The engineering of data-intensive real-time applications can be improved through adaptation of the tech-niques and principles of database management systems (DBMS), which implies a corresponding reduction in the cost of construction and maintenance. Database systems encapsulate data as a resource, and therefore pro-vide a central control of data. Consequently, instead of managing data in an application-dependent manner, database systems offer a more structured management of data, which offers the following advantages:
• Elimination of redundancy – there is only one set of data shared by different applications as opposed to each application maintaining its own version of the data; thus, better utilization of storage.
• Maintenance and integrity controls – erroneous values can be rejected before being permanently re-corded in the database, thereby eliminating corruption of information. That is, individual applications do not have to expend the extra effort in managing and maintaining the integrity of such information; rather, it becomes the system’s responsibility.
• More importantly, database systems allow the separation of policy vs. mechanism and
data-abstraction. An application only specifies its desired operations disregarding the underlying
imple-mentations and structural characteristics of the required data items. It becomes the sole responsibility of the DBMS to actually specify the storage structure and maintain it.
This qualifying dissertation is intended to review Real-Time Database Systems as part of our research ef-fort to the advancement of such systems. Due to the heterogeneity of the area and space limitations, we had to limit our presentation to only a subset of the involved design and research issues. Our choice of inclu-sion/exclusion of various topics is based on our view of Real-Time Database Systems and the associated im-portance of the issues in the overall construction and advancement of such systems. More importantly, our choice is influenced by our doctoral research intentions.
Although we intend to research Real-Time Database Systems, it is very crucial to understand the funda-mentals of the underlying conventional non-database real-time systems. Therefore, chapter one of this review is intended to discuss such fundamentals. The chapter starts with the basic definitions of time-critical systems and their timing models. These definitions are followed by a presentation of general scheduling issues that in-clude priority-based scheduling policies; i.e., Rate-Monotonic, Most-Critical-First, Earliest-Deadline-First,
Value-Density, and combined Criticalness-Deadline. Synchronization issues such as the priority-inversion
problem is discussed in more details than the preceding fundamentals, and two protocols are presented; i.e., the
Priority Inheritance and the Priority Ceiling, both of which have been proposed in the literature to reduce the
negative effects of priority inversion. The chapter concludes with a detailed discussion of overloads, outlining the impact of such operating conditions on the overall performance of the system and their theoretical limita-tions.
Chapter two covers the vast area of Real-Time Database Systems and identifies the subset of topics that we decided to include/exclude in our presentation. In the same vein as understanding the underlying fundamentals of conventional non-database real-time systems, we believe that it is also very crucial to understand the funda-mentals of conventional non-real-time database systems. Therefore, chapter two starts with an introduction to the concepts of transactions and serializability as the notion of correctness of conventional database systems. Next, we identify the differences between time-critical systems and conventional non-real-time database sys-tems, which is followed by a model of a Real-Time Database System to outline the heterogeneity of the in-volved resources and to indicate the components for which priority inclusion might be of great concern. The rest of chapter two is divided into several sections, each of which is intended to discuss a separate component of the model. These sections include transaction scheduling, admission control, memory management, and disk
scheduling.
Due to the impact and severity of concurrency control on the overall performance of Real-Time Database Systems, chapter three of this review is mainly dedicated for a detailed discussion of such an issue. The chapter starts with a presentation of locking techniques as the most basic form of concurrency control, and most com-mercially implemented in conventional database systems. As in conventional real-time systems, the priority-inversion problem is revisited under different assumptions, limitations, and solutions. Locking is followed by a discussion of optimistic (restart-based) concurrency control, followed by a detailed comparison of the two techniques due to the substantial amount of controversy that can be found in the literature regarding their per-formance under various environments. Next, we present a very recent technique in the arena of concurrency control, known as “Speculative” protocol. The technique emerged from a detailed comparison of locking-based
and restart-based protocols. It combines their advantages, while avoiding their drawbacks and shortcomings. The rest of chapter three discusses two concurrency control protocols; i.e., Multiversion, and Dynamic
Adjust-ment of Serialization Order. These protocols are very powerful schemes; both of which can be designed and
tailored in a variety of ways to suite such constraints and objectives as can be found in Real-Time Database Systems.
This review is concluded with the identification of five research areas, all of which are believed to be very important to the advancement of Real-Time Database Systems. Having identified such “open” problems, we precisely state our future plans and research intentions.
1
–
Fundamentals of Real-Time Systems
1.1. Introduction
Real-time systems can be defined as those computing systems that are designed to operate in a timely manner. That is, performing certain actions within specific timing constraints; e.g., producing results while meeting predefined deadlines. Hence, the notion of correctness of a real-time system is contingent upon the logical correctness of the produced results as well as the timing at which such results are produced [PAN93, STA
88b]
.
Typical real-time systems consist of a controlled system (the underlying application) and a controlling system (a computer monitoring the state of the environment, as well as supplying it with the appropriate driv-ing signals). The controlldriv-ing system interacts with its environment based on the data available about the envi-ronment. Therefore, it is important that the state of the environment, as perceived by the controlling system, be consistent with the actual state of the environment. Otherwise, the effects of the controlling system activities may be inappropriate. The need of maintaining consistency between the actual state of the environment and the state as reflected or perceived by the system leads to the notion of temporal-consistency. Therefore, the specifi-cation of real-time systems includes timing constraints, which must be met in addition to the desired computa-tions. Such timing constraints are usually defined in the form of deadlines associated with the various opera-tions of the computing system. In addition, such timing constraints introduce a notion of periodicity, where certain tasks must be initiated at specific instants and must be executed within specific time intervals [AUD90,
GRA92, PAN93, RAM93, and STA 88b]
.
The need to handle explicit deadlines and periodicity that are associated with activities requires employing
time-cognizant protocols [RAM93]. Such time-driven management policies should be applied on a system-wide basis; e.g., processor, memory, I/O, and communications resources (data and channels). Thus, for a set of tasks to meet their prescribed deadlines, precedence constraints must be established, satisfied, and resources must be available in time for each task. Abrupt delays at any stage of the process can disrupt the system’s behavior and objectives; i.e., delayed production of results [PAN93, STA 88a].
Scheduling decisions are guided by various metrics that depend on the application domain. The variety of metrics suggested for real-time systems indicates the different types of real-time systems that exist in the real world, as well as the type of requirements imposed on them. Different execution requirements of firm deadlines and soft deadlines lead to different system objectives, and hence, different performance metrics in comparative studies. In a real-time system that deals with firm deadlines; hence discarding tardy-tasks1, the objective is simply to minimize the number of tasks missing their deadlines. Thus, a single metric, Miss-Percentage2, is
1
Tardy tasks are those that do not complete their execution by their prescribed deadlines.
2
sufficient to characterize the system’s performance. On the other hand, a system dealing with soft deadlines, an additional metric, Average-Tardy-Time, is required to capture the degree of lateness (tardiness) of tardy-tasks
[STA93]
.
When tasks with different priorities access shared resources in an exclusive mode, a problem known as the
priority-inversion can occur, and one must take some corrective measures. Such corrective measures are not
only required to manage priority inversions, but also to cope with any overload that might occur due to unan-ticipated system activities and/or emergencies.
The rest of this chapter is outlined as follows: the chapter will start with a discussion of various system models and their corresponding timing behavior. Next, a brief discussion of scheduling will be presented, starting with static policies and progressively moving towards the more complex dynamic policies. Due to the amount of literature dedicated to the priority-inversion problem and its severe impact on the overall perform-ance of a system, the problem is presented and discussed in details in a separate section of this chapter. Finally, we conclude the chapter with a detailed discussion of overload conditions. The discussion of overload will ad-dress its impact and theoretical limitations on the system’s behavior.
The purpose of the chapter is to present the fundamentals of real-time systems and to address the real-time issues that are most relevant to the construction of Real-Time Database (RTDB) systems. The chapter outlines various issues in the domain of real-time systems. However, such issues reoccur in RTDB systems, yet require different solutions due to the differences between the two domains.
1.2. System Models and Timing
Real-time applications can be modeled as a set of tasks, where each task can be classified according to its timing requirements as hard, firm, or soft. A hard real-time task is the one whose timely and logically correct execution is considered to be critical for the operation of the entire system. The deadline associated with a hard real-time task is conventionally termed a hard-deadline. Missing a hard-deadline can result in catastrophic consequences – such systems are known as safety-critical. Thus, the design of a hard real-time system requires that a number of performance and reliability trade-off issues to be carefully evaluated [AUD90, PAN93, and STA 88b].
On the other hand, a soft real-time application is characterized by a soft-deadline whose adherence is de-sirable, although not critical, for the functioning of the system. That is, missing a soft-deadline does not cause a system failure or compromises the system’s integrity.There may still be some (diminishing) value3 for com-pleting an application after its deadline, without any catastrophic consequences resulting from missing such a deadline [PAN93, STA 88b].
Finally, a firm real-time task, like a soft real-time task, is characterized by a firm-deadline whose adher-ence is desirable, although not critical, for the functioning of the system. However, unlike a soft real-time task,
3
a firm real-time task is not executed after its deadline and no value is gained by the system from firm tasks that miss their deadlines. An interesting comparative study of soft vs. firm deadline behavior is presented in [LEE96]. The study showed that the miss-percentage of soft-deadlines increases exponentially with the arrival rate of tasks. Meanwhile, in firm-deadlines, where the population in the system is regulated automatically by dis-carding tardy tasks, the miss-percentage increases only polynomially as the arrival rate increases.
There are two general paradigms for the design of real-time operating systems known as Time-Triggered (TT) and Event-Triggered (ET) architectures, both of which are explained next.
• Systems activities in TT are initiated as predefined instants, and therefore TT architectures require the as-sessment of resource requirements and resource availability prior to the execution of each application task. Each task’s needed resources and the length of time over which these resources will be used can be com-puted off-line in a resource requirement matrix. If these requirements cannot be anticipated, then worst-case resource and execution time estimates are used. Thus, TT is prone to waste resources and lowering systems utilization under pessimistic estimates (overestimates). However, TT architecture can provide pre-dictable behavior due to its pre-planed execution pattern [BUC89, PAN93].
• System activities in ET are initiated in response to the occurrence of particular events that are possibly caused by the environment. In ET architectures, an excessive number of possible behaviors must be care-fully analyzed in order to establish their predictability, because resource needs and availability may vary at run-time. Thus, the resource-need assessment in ET architecture is usually probabilistic. Although, ET is not as reliable as TT architecture, it provides more flexibility and ideal for more classes of applications, which do not lend themselves to predetermination of resource requirements [PAN93].
As a direct consequence of these architectures along with the timing requirements we mentioned earlier, application tasks can be classified as periodic, aperiodic, or sporadic tasks [AUD90, PAN93].
1. Periodic tasks are those tasks that execute at regular intervals of time; i.e., every T time units –
corre-sponding to TT architectures. These tasks typically tend to have hard deadlines, characterized by their
pe-riod(s) and their required execution time per period [LIU73], which is usually given, by a worst-case execu-tion time.
2. Aperiodic tasks are those tasks whose execution time cannot be priori anticipated. That is, the activation of
aperiodic tasks is essentially a random event caused by a trigger – corresponding to ET architectures. Such a behavior does not allow for worst-case analysis, and therefore, aperiodic tasks tend to have soft dead-lines.
3. Sporadic tasks are those tasks that are aperiodic in nature, but they have hard deadlines. Such tasks can be
used to handle emergency conditions and/or exceptional situations. Due to the nature of hard deadlines,
worst-case calculations may be facilitated by a schedulability-constraint, which defines a minimum period between any two sporadic events from the same source.
There is a large body of literature on mixing periodic, aperiodic, and sporadic tasks within one system and there are various techniques on scheduling such a mix, each with its own advantages, disadvantages, and limitations. However, we do not intend to discuss such an issue in our current review nor do we intend to in-vestigate such an issue in our future research. The interested reader may refer to [CHE90, HOM94, SPR88, and SPU95].
1.3. Scheduling
A scheduler in general is an algorithm or a policy for ordering the execution of the outstanding processes (tasks) on a processor according to some predefined criteria. Each task within a real-time system has a dead-line, an arrival time, and possibly an estimated worst-case execution time. A task’s execution time can be de-rived from the time each resource is required and the precedence constraints among sub-tasks. Execution time information can be given in terms of deterministic, worst-case, or probabilistic estimates. The responsibility of a real-time system scheduler is to determine an order of execution of the tasks that are feasible4. Typically, a scheduler is optimal if it can schedule all task sets that other schedulers can [AUD 90, BUC89, and PAN93].
A scheduler may be preemptive or non-preemptive. A preemptive scheduler can arbitrarily suspend and resume the execution of a task without affecting its behavior. Preemption is used to control priority-driven scheduling. Typically, preemption occurs when a higher-priority task becomes runnable while a lower-priority task is executing. On the other hand, in a non-preemptive scheduler, a task must run without interruption until completion [PAN93, LIU73]. Simulation studies in [PAN93] showed that the use of preemption is more appropriate for scheduling retime systems. Finally, a hybrid approach is a preemptive scheduler, but preemption is only al-lowed at certain points within the code of each task.
Real-time scheduling algorithms can be classified as either static or dynamic [NAT92, BUC89, and PAN93]. A static approach also known as a fixed-priority, where priorities are computed off-line, assigned to each task, and maintained unaltered during the entire lifetime of the task and the system. A static scheduler requires complete priori knowledge of the real-time environment in which it is deployed. A table is generated that contains all the scheduling decisions during run-time. Therefore, it requires little run-time overhead. Aside from the many dis-advantages of static scheduling [NAT92], it is rather inflexible, because the scheme is workable only if all the tasks are effectively periodic. Jensen et al. [JEN85] stated that fixed priority scheduling could work only for rela-tively simple systems, and results in a real-time system that is extremely fragile in the presence of changing re-quirements. It was shown in [JEN85, LOC86] that fixed-priority schedulers perform inconsistently, particularly as the load increases.
On the other hand, dynamic scheduling techniques assume unpredictable task-arrival times and attempt to schedule tasks dynamically upon arrival. That is, a dynamic scheduling algorithm dynamically computes and
assigns a priority value to each task, which can change at run-time. The decisions are based on both task char-acteristics and the current state of the system, thereby furnishing a more flexible scheduler that can deal with unpredictable events.
The computational complexity of a scheduling algorithm is of great concern in time-driven systems. Scheduling algorithms with exponential complexities are clearly undesirable for on-line scheduling schemes. Audsley and Burns [AUD90] stated that the computational complexity is concerned with computability and
de-cidability.
• Computability is concerned with whether a given schedule can meet the timing constraints of a set of
tasks, a problem that can be determined within a polynomial time. The computability problem is also known as the schedulability problem [KUO91].
• Decidability is concerned with whether a feasible schedule for a set of tasks exists, a problem that is
shown NP-Complete [GAR79]. The decidability problem is also known as the feasibility problem [KUO91].
Due to the intractability of the scheduling problem, dynamic on-line scheduling techniques are based pri-marily on heuristics, which entails higher run-time costs. Dynamic on-line scheduling policies can adapt to changes in the environment and could result in greater processor utilization. In addition, dynamic methods are most applicable for aperiodic applications, most applicable to error-recovery, and most appropriate for applica-tions that lack a worst case upper limit on resource and execution requirements. Audsley and Burns [AUD90] ar-gued that no event should be unpredictable and that schedulability should be guaranteed before execution in a safety-critical system, which implies the use of static scheduling methods for such systems.
Tasks whose progress is not dependent upon the progress of other task(s), excluding the competition for processor time between tasks, are termed independent. On the other hand, interdependent tasks can interact in many ways including communication and precedence relationships [AUD90].
1.3.1. Priority-Based Scheduling
CPU scheduling is the most significant of all system scheduling in improving the performance of real-time systems [HUA89, STA91]. Conventional scheduling algorithms employed by most operating systems aim at balanc-ing the number of CPU-bound and I/O-bound jobs in order to maximize system utilization and throughput, in addition to fairness as a major design issue. On the other hand, real-time tasks need to be scheduled according to their criticalness5 and timeliness, even if it is at the expense of sacrificing some of the conventional design goals [STA 88b].
Therefore, real-time scheduling algorithms establish a form of priority ordering among the various tasks within the system. Priorities are either assigned statically during system design time as a measure of the task’s
4
If a task set can be scheduled to meet given pre-conditions, the set is termed feasible. That is, a scheduling algorithm is feasible if the requests of all tasks can be fulfilled before their respective deadlines.
importance to the system, or can be expressed as a function of time and dynamically evaluated by the scheduler
[BUC89]
. Such priorities are related to the attributes of the tasks. Since different applications have different at-tributes and characteristics, different scheduling algorithms also tend to differ in their priority assignment re-gimes. For example, priorities can be based on criticalness, deadlines, slack time, required/expected computa-tion time, amount of finished/unfinished work, age, and/or a combinacomputa-tion of such attributes [KAO95].
The objective of priority scheduling is to provide preferential treatment to tasks with higher priorities over the ones with lower-priorities. Therefore, a priority-driven scheduler prioritizes the scheduling (ready)-queue in order to service requests according to their priorities, either non-preemptively, or preemptively as we dis-cussed earlier. Consequently, the system can ensure that the progress of higher-priority tasks (ideally) is never hindered by lower-priority tasks.
In the rest of this section, we briefly discuss the various methods used in constructing different priority-driven schedulers for real-time systems.
Rate-Monotonic (RM)
The Rate-Monotonic (RM) policy [LIU73] is a preemptive policy in which priorities are assigned to tasks ac-cording to their request rates (periodicity), independent of their run-times. All tasks are statically allocated a priority according to their period. The shorter the task’s period the higher its assigned priority. The scheme is simple, because the priorities remain fixed, resulting in a straightforward implementation. The RM policy was shown an optimal fixed-priority scheduling policy for periodic tasks [LIU73].
Most-Critical-First (MCF)
The MCF policy [JEN85] is very simple. It divides the set of tasks and assigns a certain priority level to each task based on its functionality and importance to the system. The difficulty in the MCF priority assignment comes when new functions are added to the system. Such a modification in the functionality of the system might require one to adjust all other priority assignments to reflect the new additions and modifications. The policy can significantly degrade the performance of the system if the most critical tasks tend to require the most resources or tend to have longer execution times. However, the nice property of MCF is that it can pro-duce reliable schedulers in the sense that it strives to meet the deadlines of the top most critical tasks, regard-less of the systems load.
The alternative to assigning priorities statically is to derive them dynamically at run-time. Several dy-namic on-line scheduling algorithms are presented next.
Earliest-Deadline-First (EDF)
The EDF policy is a preemptive priority-based scheduling scheme. It uses the deadlines of tasks as its pri-mary heuristic. That is, the task with the current closest (earliest) deadline is assigned the highest priority in
5
the system and therefore is executed next. For a given set of tasks, the EDF policy is feasible (if and only if) iff:
(C1/T1) + (C2/T2) + … + (Cn/Tn) ≤ 1, where Ci and Ti represent the amount of computation and period
(submis-sion rate) of task ‘i’. That is, the EDF policy could achieve full processor utilization based on the above given bound. The policy is also optimal in the sense that if a set of tasks can be scheduled by any algorithm under the load limits given above, it can also be scheduled by the EDF policy [LIU73].
A major weakness of this policy is that under an overload condition, it assigns the highest priority to the task that has already missed and/or about to miss its deadline. The scheme can be made time cognizant by as-signing the highest priority to the task with the earliest-feasible deadline. A deadline is feasible if the remain-ing computation time ≤ (deadline - current time) [ABB 88a]. In addition, it was shown in a study conducted by Huang et al. [HUA89] regarding the sensitivity of scheduling algorithms to deadline distributions that the EDF is most sensitive among other scheduling policies to deadline settings. The performance of the EDF policy was shown to worsen, as the deadlines become tighter6.
Value-Functions
Jensen et al. [JEN85] introduced the concept of value-functions. A value-function is more than just a deadline in the sense that a deadline represents only one discrete instant in time, whereas a value-function models a task’s requirements over a window of continuous time frame. The essential idea is that the completion of each task has a value to the system upon the task’s successful completion, which is expressed as a function of time. Thus, the time taken to execute a task is mapped against a value that this task has to the system. Consequently, the scheduler is required to assign priorities as well as defining the system values of completing each task at any instant in time. The system’s objective is to maximize the cumulative sum of the collected values from the complete and successful execution of a given set of tasks [JEN85, ABB88]. A value-function can include a disconti-nuity to represent a deadline. For example, depending on the type of discontidisconti-nuity, a value-function can repre-sent hard, firm, and soft deadlines as shown Figure (1.1).
The value may directly correlate to the criticalness of a task, or it may be a time varying function of a task’s attributes. As can be seen from Figure (1.1), a hard deadline can be modeled so that a task can impart a full value if executed before the expiration of its deadline. However, a tardy task will impart a negative value to the system. A firm deadline task will have a value up to its deadline, and such value drops to zero after the deadline along with discarding the task. A soft deadline can be modeled by including a decay function after the deadline so that the task will still impart a positively diminishing value to the system even after its deadline is passed [JEN85, ABB88].
Value-Density (VD)
A value density function (VD) is defined as VD = value ÷ computation time. This scheme tends to select
the tasks that earn more value per time unit that they consume. Thus, the task with the greatest value density
6
receives the highest priority [JEN85, ABB 88a]. The VD policy is a greedy technique in the sense that it always schedules the task that has the highest expected value within the shortest possible time unit.
The simulation conducted in [JEN85] showed that the performance of the VD policy is variable depending on the value-function chosen and on the systems load. Because it is a greedy algorithm, it picks up a value early rather than waits to get a higher value; thus, it (unnecessarily) misses many opportunities to meet time con-straints. Value Time Deadline Hard Deadline Firm Deadline Soft Figure (1.1)
Combined Criticalness-Deadline
Scheduling real-time tasks is priority-driven, where priorities are based on some characteristics of the cor-responding tasks; e.g., deadline and/or criticalness. Biayabani et al. [BIY88] argued that scheduling based on pri-orities where pripri-orities are derived from deadlines or criticalness (separately) is not adequate, because tasks with very short deadlines might not be very critical, and vice versa. An important point that is addressed in the literature is that criticalness and deadlines are two separate independent characteristics that do not correlate in one-to-one relationship [HUA89, KAO95]. Based on this observation, many attempts have been made to combine the two attributes into the scheduling decision. In the rest of this section, we present a few of such attempts.
Biayabani et al. [BIY88] introduced two scheduling algorithms ALG1 and ALG2, both of which integrate deadlines and criticalness in deriving the corresponding priorities. The two algorithms attempt to schedule an incoming task according to its deadline, ignoring its criticalness. If scheduling the task is feasible, then sched-uling is successful. However, if the newly incoming task is not schedulable due to having too many tasks al-ready in the system, the algorithms attempt to schedule the incoming task on the expense of the less critical previous tasks in the system. The two algorithms differ only in how they remove the lower critical tasks from the system. ALG1 removes lower critical tasks one at a time from low to high criticalness order. ALG2 also re-moves lower critical tasks one at a time, but starting from the tasks with the least criticalness and furthest deadlines. Note that Biayabani et al. [BIY88] relocates the removed task(s) to another processor, a point that we do not address in this review.
Both algorithms apply EDF for under-load conditions. However, in overload situations, ALG1 switches to
MCF, whereas ALG2 switches to another policy that is an artificial combination of EDF and MCF. If
sched-uling was based on EDF and MCF together at the same time then it is a natural combination. However, since the scheduling decision under an overload is based on MCF first, then on EDF, the two policies are not actu-ally integrated into one measure and therefore we believe it is an artificial combination of the two policies.
The simulation conducted by Biayabani et al. [BIY88] revealed that at low loads, deadline-based algorithms tend to perform better than criticalness-based algorithms. On the other hand, at high loads, the situation is re-versed and the criticalness-based algorithms outperform deadline-based algorithms. Furthermore, combining the deadlines and criticalness together in one policy; e.g., (ALG1 and ALG2) can outperform both deadline-based and criticalness-deadline-based algorithms.
Huang et al. [HUA89] proposed an on-line scheduling algorithm called Criticalness-Deadline First (CDF) in which each task is assigned a priority at the time of its arrival, based on its relative-deadline7 divided by its criticalness. Huang et al. [HUA89] showed that CPU scheduling based on the CDF policy significantly improves the overall performance of the system over techniques that consider deadlines or criticalness as separate pa-rameters. Furthermore, the CDF policy was shown to achieve a good performance for the more critical tasks at the cost of losing the less critical tasks. This trade-off reflects the nature of real-time processing that is based on criticalness and timing constraints. Thus, to get the best performance, both criticalness and deadlines should be used for CPU scheduling.
The study conducted in [STA91] concluded the following points. First, in a CPU-bound system, the CPU scheduling algorithm has a significant impact on the performance of a real-time system, and dominates all of the other types of protocols. Second, in order to obtain good CPU scheduling performance, both criticalness and deadlines of a task should be considered in priority assignment.
Buttazzo et al. [BUT95] proposed another value-deadline combined technique known as a weighted Earliest
Deadline Value Density First (EDVDF). We defer the discussion of the EDVDF policy to the overload section,
towards the end of this chapter.
1.4. Synchronization
Real-time tasks interact in order to satisfy system wide requirements. Such interactions range from simple synchronization to mutual exclusion protection of non-sharable resources. To calculate the execution time for a task requires knowledge of how long it will be blocked on any synchronization primitive it uses. Ideally, a higher-priority task, TH, should be able to preempt a lower-priority task, TL, immediately upon request.
How-ever, to maintain consistency of a shared resource, the access must be serialized. If TH gains access first, then
the proper priority order is maintained. On the other hand, if TL gains access first followed by a request from
TH to access the shared resource, TH is blocked until TL completes its access to the shared resource.
The primary difficulty with blocking mechanisms is that a higher-priority task can be blocked by a lower-priority task possibly for an unbounded number of times and for unbounded periods – a phenomenon known as the priority-inversion problem. Unfortunately, TH, mentioned above, is not only blocked by TL, but it ends up
waiting for any medium priority task, TM, that wishes to execute during that period. Task TM will preempt TL
7
and hence further delay TH, whose progress became dependent on that of TL. Such priority inversion could
mature into a serious problem in real-time systems due to its role in lowering both, schedulability as well as
predictability of the system [SHA90].
There are various methods that can be integrated with the scheduler to reduce the negative effect(s) of the priority inversion problem, two of which are presented in the following subsequent sections.
1.4.1. The Priority Inheritance Protocol
Under the priority-inheritance protocol [SHA90], when a task blocks one or more higher-priority task(s), it inherits the highest priority level of all the tasks it blocks and executes its resource (critical section) at such an elevated priority level. After exiting its critical section, it returns to its original priority level. Consequently, a lower-priority task TL directly blocks a higher-priority task TH (temporarily – only for the duration of the
criti-cal section). Such blocking is necessary to ensure mutual exclusion and the consistency of criticriti-cal section exe-cution. Furthermore, a medium priority task TM will also be blocked by the elevated priority task to avoid
hav-ing TM preempt TL, thereby indirectly preempting or delaying TH 8.
The priority inheritance criterion is transitive. That is, given T1, T2, and T3 as three tasks with T1 having
the highest priority and T3 having the lowest priority. If T2 blocks T1, and T3 blocks T2, then T3 inherits T1’s
priority through T2’s inheritance. Effectively, T1 is blocked by both lower-priority tasks T2 and T3. In addition,
when a task inherits a higher-priority, it uses the elevated priority in competing for all its resource needs dur-ing the duration at which its priority is elevated.
1.4.2. The Priority Ceiling Protocol
The priority ceiling protocol [SHA90] extends the priority inheritance protocol in order to prevent the for-mation of deadlocks as well as chained-blocking9, both of which are experienced by the priority-inheritance protocol presented above. The priority ceiling protocol is as follows:
• Assign a priority level; i.e., a ceiling, to every critical section (CS). The ceiling is set equal to the highest priority level that may use or access this CS.
• A task wishes to access a CS can simply do so if there are no suspended tasks within their CSs.
• If a task is suspended while executing within a CS due to preemption by a higher-priority task, then the priority ceiling comes into effect. If the higher-priority preempting task, TH, has a priority that is
higher than all ceilings of all currently preempted tasks, then it can access its CS. Otherwise, TH is
suspended, the lower-priority task, TL, inherits the priority of TH, and TL resumes execution at the
ele-vated priority level.
• When a task exits its CS, it returns to its original priority if it had inherited any higher priority during its execution.
8
The priority ceiling protocol achieves what it is designed for; that is, prevent transitive blocking
(chained-blocking) and prevents deadlocks as well. However, it has the following problems.
• The performance of the algorithm is very sensitive to the size of the critical section(s) [GRA92].
• Consider two tasks T1 and T2 where T1 has a higher priority and may wish to access many critical
sections. However, T2 accesses only a single critical section and it happened to be in common with T1.
If T2 accesses the common critical section first, then T1 cannot access any of its other critical sections.
Although, the common critical section, could be embedded within a conditional statement and may never actually be accessed by T1.
• If T1 and T3 have a critical section in common and therefore the priority ceiling of the critical section
is set to the priority of T1. Assume that T3 accesses the critical section, and T2 arrives and preempts
T3, while T1 has not even arrived. T2 cannot access any of its critical sections due to the push-through
blocking effect. The main reason behind push-through blocking is to prevent T2 from indirectly
blocking T1. However, as a side effect to it, T2 will block even if T1 is not in the system yet. Imagine
the same scenario between T1 … T100, with T100 having the lowest priority in the system. T100 can
ac-tually block T1 … T99, directly and via push-through blocking, which could cause T1 … T99 to miss
their deadlines due to being blocked by the absolute lowest priority task, in a priority-driven system! The interested reader may find a detailed presentation of the priority-inheritance and the priority-ceiling protocols in [RAJ91, and RAJ95].
1.5. Overload
A system is under-loaded if there is a schedule that will meet the deadline of every task. We have pre-sented several on-line scheduling algorithms for a uniprocessor environments. However, none of the prepre-sented algorithms actually makes any performance guarantees when the system is overloaded. Practical systems are prone to intermittent overloading caused by any of the following factors:
• A cascading of exceptional situations, often corresponding to emergencies.
• Effective scheduling decisions require complete knowledge of the execution time of a task. Meanwhile, execution times are generally stochastic in many systems and environments [BAR91a]. Using worst-case exe-cution times to schedule a set of tasks could reduce the processor utilization under normal operating con-ditions. On the other hand, scheduling using less than worst execution times introduces the possibility of an overload.
• If worst-case calculations were too optimistic, or the hardware fails to perform as anticipated.
A practical on-line scheduling algorithm should not only be optimal under normal circumstances, but also respond appropriately to overload conditions [BAR91a].
9
An on-line scheduling algorithm is said to have a competitive-factor (r) on a set of tasks, iff it is guaran-teed to achieve a cumulative value ≥ r of the value achievable by a clairvoyant scheduling algorithm on the same set of tasks – where 0 ≤ r ≤ 1. A clairvoyant scheduling algorithm is the one that knows the arrival time, value, execution time, and deadline of all future task requests [BAR91a, BAR91b].
An optimal on-line scheduling algorithm such as EDF has been shown to achieve r = 1, when the
loading-factor (f) ≤ 1. For a uniprocessor environment, Baruah et al. [BAR 91a, and BAR91b] have proven that no on-line scheduling algorithm can offer r > 0.25 (or ¼) under f ≥ 2 + ε, where ε is an arbitrary small positive number. This implies, in contrast to EDF whose competitive factor crumbles at f > 1, that there could exist an on-line scheduling algorithm whose performance can be optimal for 0 ≤ f ≤ 2. However, for 1< f ≤ 2, Baruah et al. [BAR
91a, BAR91b]
showed that an on-line scheduling algorithm may not obtain more than [1÷ (1+ k )2] of the value obtainable by an off-line clairvoyant algorithm; where k is the ratio of the highest value density to the lowest value density of the tasks within the system. Such a bound rapidly drops below 0.25 as the value density differs among the competing tasks within the system.
In contrast to the theoretical bound presented above, Buttazzo et al. [BUT95] argued that such an upper bound has only a theoretical validity, because it is achieved under very restrictive (almost unrealistic) set of as-sumptions. For example, tasks have zero laxity, task’s execution time can be very short (epsilon short which Baruah et al. called baits), and each task’s value is equal to its computation time.
Buttazzo et al. [BUT95] conducted a comparative study for four scheduling policies: EDF, MCF, VD, and a weighted Earliest Deadline Value Density First (EDVDF). Where the priority Pi derived by EDVDF is
com-puted as follows: Pi = (α) VDi – (1-α) di, where Pi, VDi, and di represent the priority, the value density, and
deadline of task ‘i’, respectively. The four policies were further extended to manage overload in two different manners. Either simply reject the incoming task(s) or remove the task(s) with the least value or criticalness (depending on the priority assignment policy being used) until the removal of the overload. Note that for the
MCF policy, the value of a task correlates directly to its criticalness. The first method was called the guaran-teed-class, while the second was called the robust-class. In addition, the later was also equipped with a queue
to hold all rejected (removed) tasks, which will be processed only if active tasks finish their execution earlier than was anticipated. The simulation conducted in [BUT95] showed the following results:
• In the presence of an overload and without any mechanism to deal with an overload, the VD policy was the most effective policy among the simulated four algorithms. In addition, the VD policy degrades gracefully and less sensitive to the tasks parameters.
• In the presence of an overload and with an overload management mechanism, whether employing the
ro-bust or the guaranteed overload management strategy, the EDF policy seems to be the most effective.
The conclusion of Buttazzo et al. [BUT95] was that scheduling by deadline before an overload and by value during an overload works best in most practical conditions. However, with respect to the second point reported by Buttazzo et al. [BUT95] above, the reader should note that there is no correlation between the deadlines and the values of the removed tasks. That is, if tasks are removed based on their values in order to bring the load down to the feasible systems capacity, the removed tasks could actually be the set of tasks with the furthest deadlines. On the other hand, the remaining most-value tasks could be the ones with tight deadlines and sub-jected to abortion. In fact, the remaining most-value tasks could have infeasible deadlines. The behavior of
EDF policy, which we have reported earlier, depends heavily on the distribution of the deadlines [HUA89]. The results reported in [BUT95] must be based on a distribution opposite to our argument above. That is, Buttazzo et al. [BUT95] must have had a distribution where the most valuable tasks happened to have the furthest (loosest) deadlines. Buttazzo’s et al. skewed distribution could result from many parameters in a simulator, for example, the random number generator and its seed(s).
We wish to conclude this section with the following comment: When a real-time system is overloaded, not all tasks can be completed by their deadlines. Therefore, many researchers state that the objective of a sched-uling algorithm should be to schedule at least the most important tasks. However, we have not come across any research that actually indicates what constitutes the “most important tasks”. That is, many researchers seem to echo the above statement, yet, to the best of our knowledge, no one had taken the initiative to actually define what constitutes the “most important tasks” within a system. We believe that the lack of a precise definition of the tasks’ importance, known as criticalness, is a gap in the knowledge of the real-time community. One needs to precisely define whether criticalness is a static or a dynamic value that varies in correspondence to the sys-tem’s mode, operating environment and conditions, the tasks’ present and past behavior, in addition to the tasks’ requirements as well as many other parameters. However, until a concise definition of the “most impor-tant tasks” is formulated, scheduling the most imporimpor-tant tasks is an incomplete claim.
In the next chapters of this review, various design issues will be addressed along with the proposed solu-tions to every strategy. We will list many of the important issues but we limit our discussion and presentation to only a subset of such issues. In presenting various solutions, we intend to list such solutions in chronological order, which will lead us through the advancement of RTDB systems over the last decade. Such advancement leads in turn to our future research intentions and identifies the general areas that we wish to investigate.
2
– Overview of
Real-Time Database Systems
2.1. Introduction
In this chapter, we address various issues that impact the design of RTDB systems. Not until one attempts to survey the field of RTDB systems, one realizes the massive amount of information to be reviewed. For ex-ample, a list of topics with consequential severity on the overall design of RTDB systems, in a centralized
uni-processor system, is as follows:
1. RTDB System Models
2. Scheduling RTDB Transactions 2.1.Concurrency Control 2.2.Conflict Resolution 2.3.Deadlocks
3. Fault Tolerance and Failure Recovery 4. Admission Control
5. Memory Management 6. I/O and Disk Scheduling 7. Imprecise Computations
8. Main Memory Database Systems
9. Minimizing Transaction Support; i.e., Relaxing Serializability 10. Access Invariance
11. Predictability
Due to the heterogeneity of the issues, space limitations, and our future research intentions, we will only address the following issues: 1, 2.1-2.3, 4-6. Out of the remaining issues: Recovery is a major issue and the interested reader may refer to [HAE83, SHI86, BER87, UPA88, LEC88, KOR90, NIC90, MOH92, ELM94, SIV95, THO95, and HUA96]. Access
Invariance and Predictability have a strong correlation and the interested reader may refer to [FRA90, FRA92, ONE95,
KIM93, and KIM96]
. Finally, Minimizing Transaction Support; i.e., Relaxing Serializability is a massive topic. Only a fraction of the attempts in this area include Epsilon Serializability [PU91a, PU91b, RAM94, WU92], Semantic Analysis
[GAR83, BAD92]
including SAGAS [GAR87], Weak Consistency [GAR82], Quasi Serializability [DU89], Pre/Post
Condi-tions [KOR88], Eventual Consistency [SHE90], Controlled Inconsistency [ALO90], Relaxed Atomicity [LEV91], and the
We start this chapter by presenting a very brief overview of conventional database issues and introduce the concepts of transaction and serializability, which will ease the discussion of subsequent sections and the next chapter. Topics with consequential severity on the overall design of the system will be discussed in more de-tails than other less important topics. However, due to our future research interest and the amount of informa-tion in the literature regarding concurrency control, we only introduce the topic in this chapter and we dedicate the next chapter for the detailed discussion of concurrency control. Our final note before we start the chapter is the following note quoted from M. Graham [GRA92], “it is not possible to determine if there exists best or
uni-versal solution to many of the design issues in RTDB systems. It seems reasonable to assume that for every solution, there is a problem, which it does not fit”. However, we believe that making the solution fit that one odd problem, is one way to advance our knowledge of RTDB systems, and on such a goal we strive.
2.2. The Concept of Transactions and Serializability
The state of a database consists of records, assertions about the values of these records, and an allowed set of transformations applicable to the values of such records. These assertions are called consistency constraints. One may need to temporarily violate the consistency of the system-state while modifying it. Therefore, in order to transform a consistent system-state to another consistent state, the system provides sets of actions in the form of read and write operations. A transaction is a collection of such actions, which comprise a consistent transformation of the system-state. Each transaction, when executed alone, transforms a consistent state into a new consistent state; that is, transactions preserve consistency of the database information [ESW76, GRA81a, BER87,
and CHR94]
.
Interleaving transactions access to the database can maximize throughput and resource utilization. There-fore, various actions of different transactions need to be executed with maximal concurrency by interleaving actions from several transactions while continuing to give each transaction a consistent view of the database. A particular sequencing of the actions from different transactions is called a schedule. A schedule that gives each transaction a consistent view of the database-state is called a consistent schedule [ESW76]. However, failures and concurrency are the two sources of potential errors that can lead to database inconsistencies. Traditional data-base management systems (DBMS) prevent such inconsistencies by satisfying four properties associated with transactions, known as the ACID properties [GRA93, CHR94].
A Atomicity: Either all or none of the transactions operations are/is performed.
All the operations of a transaction are treated as a single, indivisible, atomic unit.
C Consistency: A transaction maintains the integrity constraints on the database.
I Isolation: Transactions can execute concurrently but with no interference with each other’s operations.
D Durability: All changes made by a committed transaction become permanent in the database,
While each transaction preserves the consistency of the database at its boundaries, recovery protocols are used to ensure the atomicity and durability properties. Finally, isolation can be insured by concurrency control protocols [GRA93, CHR94].
Generally, a particular transaction depends only on a small part of the database-state. Therefore, one tech-nique for avoiding conflicts is to partition entities into disjoint classes. One can then schedule transactions concurrently only if they use distinct classes of entities. Transactions using common entities must still be scheduled serially. If such a policy is adopted, then each transaction will see a consistent version of the data-base-state [ESW76]. Some systems try to guess the read/write sets in advance and do set-intersection at transac-tion scheduling time to decide whether a transactransac-tion conflicts with some already executing transactransac-tion(s). In such cases, initiation of a new transaction is delayed until it does not conflict with any running transaction. IMS/360 seems to have been the first to try this scheme, it has not been very successful, and pre-declaration was abandoned by IMS [GRA 81a, sighting OBE80]. Thus, based on IMS/360 past unsuccessful experience, one can confidently state that it is usually impossible to examine a transaction and decide exactly which subset of the database it will use. It is not uncommon for a transaction to lock the set of all entities within a certain value; e.g., key addressing. The size of such a set could only be determined at run-time, possibly by examining the entire database. Therefore, such a partitioning scheme has been abandoned in favor of the more flexible scheme where individual entities are acquired dynamically [ESW76].
When data objects are acquired/locked dynamically, a transaction requesting an object may wait if the re-quested granule is already acquired by another transaction. Distinguishing between two lock modes can ac-commodate multiple readers. One mode indicates an update access while the other indicates a read access. Read locks are compatible while update locks are not [GRA81a].
A traditional transaction may have various execution paths within its body, and the actual path to execute is dependent on run-time parameters. The difficulty of dealing with traditional transactions is that different execution paths have significantly different requirements. Thus, it is impossible to quantify such requirements without being overly too pessimistic/optimistic and thereby overly overestimating/underestimating resource re-quirements. Canned transactions are special type of transactions [DAT96], which are distinguished by having a repetitive recurring behavior and requirements. That is, when a canned transaction is triggered in order to cor-rect a certain condition or to accomplish a specific chore, it is the same transaction that was previously trig-gered on the same event. In any traditional transaction, there might exist a number of different execution paths, whereas in a canned transaction, there is only one execution path. In other words, canned transactions have a fixed read/write-set for every single activation, which does not depend on any run-time parameters.
The correctness of the individual transactions is sufficient for the database consistency only for a serial execution. However, due to interleaving of conflicting operations from separate transactions, a concurrent exe-cution may violate the database integrity constraints regardless of the correctness of individual transactions. Thus, conflicting operations need to be ordered in a non-interleaved (serial) manner in order to maintain the database consistency [CHR94]. In other words, an execution is said to be serializable if it produces the same
out-put and has the same effect on the database as some serial execution of the same transactions. Since serial exe-cutions are correct, and since each serializable execution has the same effect as a serial execution,
serializabil-ity becomes the notion of correctness in any DBMS [BER87].
There are several versions of serializability. The simplest and most common form of serializability is
con-flict-serializability. Conflict serializability insures that conflicting operations appear in the same order in two
equivalent executions. That is, two operations conflict if their effects on the database depend on their execution order; i.e., read and write operations on the same data object [BER87, CHR94].
On the other hand, View serializability is not concerned with the order of conflicting operations. Rather, two executions are equivalent if each transaction reads the same values in the two executions, and the final value of the database is the same in both executions. View serializability allows more concurrency than conflict serializability, but it is NP-Complete to test whether an execution is view-serializable [BER87, CHR94, PAP84].
Recoverable History
If a transaction Tj reads a value that was last written by an aborted transaction Ti, then Tj must also be
aborted. This situation is known as cascading-aborts [BER87, CHR94]. For an execution to be durable, once a transaction commits, it could not subsequently be aborted nor its effects changed due to cascading-aborts. An execution is recoverable if, once a transaction is committed, the transaction is guaranteed not to be involved in cascading aborts. That is, an execution is recoverable if it is cascadeless, which ensures that every transaction reads only data values written by committed transactions, thereby avoiding cascading-aborts. Consequently, if transaction Tj reads a value from Ti, then Ti must commit before Tj. Thus, to assure atomicity and durability,
an execution must be recoverable. A strict execution ensures that every transaction must read and write only data values written by committed transactions [BER87, CHR94]. Note that a cascadeless execution requires reading from committed transactions, whereas a strict execution requires reading and writing from committed transac-tions. Therefore cascadeless is a proper subset of strictness, and a strict execution implies a cascadeless execu-tion.
• Cascadeless: Read only committed written data. That is, if transaction Tj reads from Ti, then Ti must be an
already committed transaction; i.e., Wi [x] → Rj [x] ⇒ Ci→ Cj
• Strict: Read and write only committed written data. That is, if transaction Tj reads from Ti, or overwrites a
data item that was last written by Ti, then Ti must be an already committed transaction; i.e.,
Wi [x] → Rj [x] ⇒ Ci→ Cj
Hence, Cascadeless ⊂ Strict, and therefore, Strict ⇒ Cascadeless. A cascadeless execution is faster than a strict execution, and it ensures durability and recoverability. However, it is subject to the lost-update problem. The lost update problem occurs when: Wi [x] → Wj [x] and Cj→ Ci. That is, the commitment of Ti erases the
update of Tj although Tj’s update was performed after that of Ti’s. Thus, Tj’s update is a lost-update. On the
other hand, a strict execution ensure durability, recoverability, and is not subjected to the lost-update problem; however, it is slower that a cascadeless execution. Based on this observation and since some data is persistent while other data is perishable, is there any systematic technique that could automatically switch between a strict and cascadeless executions based on the data that is being handled? Therefore, one of the first issues that one must investigate is the adaptability and adequacy of such executions to a RTDB environment.
2.3. Time-critical Systems vs. Database Requirements
In this subsection, we list the major differences between traditional real-time systems and conventional database systems. It is important to identify and recognize the differences between the two technologies due to the residual impact on the corresponding design issues in the combined field, RTDB systems.
1. Database systems are designed to maintain the database consistency, and the correctness of the database operations is hardly affected by the timeliness of the transactions. Meanwhile, real-time systems are de-signed to deal with timing constraints abstracting away the notion of data consistency and integrity. Con-sequently, the primary goal of database systems is to minimize the response time in order to achieve a good throughput, while the primary goal of real-time systems is meeting the stringent timeliness of the underlying applications. Combining the two technologies also means combining their design objectives and constraints. Therefore, RTDB systems have inherited the properties; i.e., objectives and constraints, of both systems. Timeliness of the results and maintaining the integrity of the database together form the cor-rectness criterion of any RTDB system. Therefore, management of time-critical information through a da-tabase system requires the integration of concepts from both fields in order to properly handle timing con-straints and data consistency [ABB 88b, BUC89, HUA89, RAM93, SIN88, STA 88a, ULU92, and ULU 95b].
2. Scheduling algorithms in the two systems, DBMS and real-time operating systems; differ in their schedul-able units. While tasks are considered as the schedulschedul-able unit in real-time systems, transactions are the schedulable unit in DBMS.
• Tasks typically include an arrival time, deadline, worst-case execution time, and criticality. In addi-tion, a task may also include a resource list, where data is rarely considered as part of it. Therefore, the majority of time-critical scheduling algorithms depend heavily on a worst-case execution time, making the processing of time-critical tasks highly predictable [GRA92].
• Transactions, on the other hand, do not carry any timing information other than their arrival time. In addition, transactions tend to have extensive data resource requirements, which usually are acquired dynamically.
Unpredictability is infested in RTDB systems due to the assumptions that have been made in
building conventional database and operating systems. Virtually, it is impossible to predict the re-sponse time for a transaction due to intricate protocols such as paging working sets, dynamically as-signing and adjusting priorities, I/O scheduling, buffering, concurrency control among various trans-actions, commit protocols, and recovery protocols. Hence, the assumption of a well-known worst-case execution time is not valid for general database transactions. Thus, it is generally impossible to stati-cally determine all possible schedules in order to guarantee meeting real-time constraints. Further-more, the order-of-magnitude difference between CPU and I/O times pessimistically overestimates page faults; thereby execution times are inflated, resulting in very low system utilization [ABB 88b, BUC89,
GRA92, and STA88b]
. Therefore, it is argued in [STA 88b, HAR92, and KAO95], that RTDB systems are not suitable for hard real-time constraints due to the limitations of the current technology and its consequent un-predictability.
Finally, the atomic nature of a transaction requires that the effects of any failed transaction not be visible to any other transaction. Therefore, concurrently executing transactions must be isolated from each other. Thus, a transaction is a unit of recovery while a task is not. A task may require a certain degree of recovery; however, a task’s recovery revolves around the task’s own data. Meanwhile, a transaction’s recovery is concerned with recovering the contents of the database, as a shared resource among all transactions within a system. Therefore, the resulting delay of a task’s recovery may effect the task’s own execution, whereas the resulting delay of a transaction’s recovery may effect the trans-action’s own execution as well as the execution of other transactions in the system.
3. Preemption is generally used in real-time systems to enhance the overall performance; however, preemp-tion could have severe consequences in database contexts. Preempting a transacpreemp-tion while it holds lock(s) on data items may initiate rollbacks if the transaction were to be involved in conflict(s) while being pre-empted. Such rollbacks imply undoing accomplished work, in addition to redoing the work, if/when the preempted transaction is restarted. The resultant delay and the wasted execution time may cause the trans-action as well as other transtrans-actions to miss their deadline(s). The net result may be degeneration in per-formance, and therefore, a preemption decision in a RTDB system should be made carefully [STA 88b].
4. Real-time system schedulers have to deal with overload situations. Overload-management policies make sure that the most critical tasks are still executed at the expense of the less critical tasks. Database sched-ulers simply attempt to complete all pending work, typically slowing performance across board [BUC89].
5. In a conventional non-real-time database system, not accessing the database leaves the database in a con-sistent state. That is, the database consistency may only be violated by erroneous transactions and errone-ous synchronization of transactions to the contents of the database. Note that we excluded recovery since we do not discuss the issue in this review. However, a significant portion of the data in RTDB system envi-ronments is highly perishable in the sense that its validity is highly time-dependent. Thus, in addition to the causes of inconsistency listed above, the database consistency may also be violated in RTDB systems if
such temporal data is not updated in a timely manner. Therefore, while not accessing the contents of the database in conventional database systems maintains the consistency of its information, a timely access of the database becomes a necessity for maintaining its consistency in RTDB systems. Such temporal data imposes unique temporal constraints, which demands time-cognizant transaction processing [GRA92, STA88b,
and RAM93]
.
Many real-world applications involve time-constrained access to data, as well as access to data that has temporal validity. Such applications involve gathering data from the
