Missing:
1
REFINING TIMING CONSTRAINTS OF APPLICATIONS IN DEEDS Jonas Mellin, Jorgen Hansson and Sten F. Andler Department of Computer Science University of Skovde, Sweden
ABSTRACT The DeeDS prototype integrates active database functionality and critical timing constraints from active and real-time databases. This is combined with unique distribution and integrated monitoring techniques. The aims are to avoid important sources of unpredictability, to guarantee schedulability, and to make scheduling and event monitoring predictable. Our solution to the rst item is based on the use of bounded as-soon-as-possible replication and main memory residency. The second item is handled by overload ltering, which is based on the concepts of criticality and contingency plans. The last item, based on o -loading, is covered in-depth by introducing necessary assumptions for predictability. We present a mathematical model for re ning important application design constraints, which is useful for prototyping.
1 INTRODUCTION Distributed processing and sharing of large amounts of data under critical timing constraints are needed by many complex real-time systems. Real-time database systems are thus an important component in such complex systems, since they provide ecient storage and access to shared data as well as predictable transaction execution, thereby eliminating the need for ad hoc methods in these respects. Real-time systems have two fundamental characteristics. First, the time at which a result is presented to the environment is of paramount interest, requiring that real-time systems explicitly consider the time dimension in their execution model. Second, real-time systems interact with the environment through sensors and actuators, where an actuator presents the response, 1
2
Chapter 1
computed by the real-time system, to a certain event/situation detected by a sensor. In other words, the real-time system reacts to external stimuli, and parts of this reactive behavior can be modeled by an active database. We are here describing the Distributed Active Real-Time Database System (DeeDS) prototype [1, 2]. DeeDS is an event-triggered real-time database system, using dynamic scheduling of a set of transaction types of mixed criticality. These transactions can have hard, rm, and soft deadlines, where hard deadline transactions are considered critical and their workload is known a priori. In DeeDS, the reactive behavior is modeled using Event-Condition-Action (ECA) rules [9] extended with mechanisms for modeling timing constraints. The action part of the rule is associated with a deadline, which is relative to the event occurrence time, implying time-cognizant event detection and rule evaluation. In DeeDS, predictability of transaction execution is enforced by removing sources of unpredictability such as disk and network accesses from the critical path, and developing predictable implementations of critical system services such as the scheduler and the event monitor. This chapter focuses on some important design issues and constraints for active real-time database systems in general, and speci cally, constraints imposed by the critical system services in the DeeDS prototype. We present the DeeDS architechture with its components and a model for analyzing the system properties. The model allows us to re ne two important design constraints, namely minimum interarrival time of events, and worst-case minimum delay (or earliest possible release time). It takes into account primitive and composite events, event showers, dynamic scheduling of mixed transaction types, and hybrid monitoring. The rest of this chapter is structured as follows: In section 2 we give a short description of the DeeDS architecture and its components. In section 3 a detailed problem de nition is speci ed for providing predictable system services. Further, the basic interaction model between the scheduler and the event monitor is presented. Section 4 describes related work. Finally, in section 5 conclusions are presented.
2 DEEDS ARCHITECTURE The DeeDS architecture is mainly layered where the layers are tightly coupled, i.e., they use the procedure calls for interlayer communication and the layers can access necessary information about each others internal state. Moreover, the
Re ning Design Constraints in DeeDS
3
Real-time applications
DeeDS Services Rule manager Event monitor
OBST on other nodes
Replication and concurrency
OBST object store
Scheduler
tdbm storage manager
OSE Delta + Extended file system Application Processsor
Event Criticality Checker
Dispatcher OSE Delta Services Processor Loose coupling Tight coupling Distributed communication
Figure 1
The DeeDS architecture
architecture of DeeDS is divided into application-related functions and critical system services. In order to o -load the processor running application tasks, named the application processor, the critical system service module runs on a dedicated processor named service processor. Further, DeeDS uses a dual processor hybrid-monitoring solution, e.g., where one processor is dedicated for monitoring another processor which executes a software instrumented application [13]. Both processors execute a distributed real-time kernel (OSE Delta) providing both application related tasks and system services a generic interface to the hardware. By assigning dedicated processors to the services separated by their functionality ( g. 1), gives us advantages when predicting the behavior. Moreover, the system services are less dependent on the application transaction
4
Chapter 1
execution, which simpli es our model. Furthermore, it makes it possible to use milestones to measure progress of application tasks [14].
2.1 Application Services The application-related functions are decomposed into the rule manager module (RMM), the object store (OBST) [7], the storage manager (tdbm) [5], and the replication and concurrency control functions. The application-related modules are layered. By replacing the storage manager in OBST with tdbm, nested transactions are supported [17]. In our description we will focus on the RMM and the replication and concurrency control functions. The RMM provides rule storage, rule selection, and condition evaluation. As mentioned previously, DeeDS uses an extended form of ECA rules, where timing constraints may be speci ed for the action part. Upon the occurrence of an event E , all rules associated with the event are triggered. The condition part C of each of the triggered rules is evaluated to determine whether the condition is ful lled, i.e, if the corresponding action A should be executed. Events are detected by the event monitor module (see below) and then forwarded to the RMM as event instances. The rules that are associated with an event can be eciently retrieved. The action is sent to the scheduler (see below) to be scheduled and executed subject to the timing constraints, if any. An alternative action to be taken in the case that a deadline cannot be met can also be speci ed. The replication and concurrency control functions handle data distribution and synchronization of accesses to data. To ensure predictability in DeeDS, the following design decisions have been made to control or eliminate delays. Delays occur due to disk accesses and network communication when manipulating data, as well as distributed commit processing. First, to avoid unpredictable disk delays, the database is main memory resident. Second, the database is fully replicated, i.e. each node has a copy of the entire database, to avoid unpredictable communication delays. Third, a bounded as-soon-as-possible (BASAP) replication scheme is used when propagating updates of the database, to avoid unpredictable distributed commit delays. This implies that temporary inconsistencies may arise in the database and must be tolerated by applications. Since main memory typically is volatile, recoverability without unpredictable delays requires writing of the log tail to stable high-speed memory, complemented by o -loaded staging of the log and checkpointing to secondary storage [10]. The potentially large database size in certain systems may make the use
Re ning Design Constraints in DeeDS
5
of virtual replication attractive. With this we mean that, logically, all data is still replicated in each node. However, portions of the database not used at a particular node need not be physically replicated at that node (unless for reliability reasons). Since all data items are available locally, transactions in DeeDS are not distributed. All data are read and updated locally (in main memory) and BASAP replicated after transaction commit [12], without undue delay and in a way that guarantees eventual consistency. DeeDS enables the application to tolerate potential temporary inconsistencies by providing a con gurable con ict detection and resolution mechanism which allows the user to specify appropriate con ict resolution policies. To this end, a distinction is made between data accessed by one or more readers or updated by one or more writers, as well as data with di erent degrees of permanence (e.g. sensor data, derived data, data requiring database consistency). The user also needs to know when an update has become stable, or, conversely, in which time interval updates could have occurred which may not yet have been applied to a data item.
2.2 Critical System Services The critical system services consist of an event monitor (EMM), an event criticality checker, and a real-time scheduler. These services are provided by the service module working at all layers. The application-related modules are loosely coupled with the service module. The EMM delivers event instances, i.e. representations of event occurrences described by their associated event types, to the recipients upon detection within a bounded time. The event detection algorithm starts when it is noti ed of an event occurrence and nishes when all event instances are passed to the recipients. The EMM is initially given an event speci cation consisting of the event types and their associated recipients. The event type description is based on operator grammars, where operators are named constructors as they are part of the composition of events. Event graphs, whose basic structure is equivalent to the graph for parsing operator grammars, are used for event detection, which includes event composition [8]. Event instances are composed, i.e. pushed upwards from the leaf nodes (i.e. the primitive events) to the nodes representing by constructors, according to the constructors and the composition policy (event context [8]). When a node, associated with a set of recipients, is reached the recipients are noti ed by using a bounded atomic broadcast. All event instances carry at least information about its type, time of occurrence, and the scope, e.g., transaction, in which it was generated. For example, an event
6
Chapter 1
instance of an event type representing a method call also contains the parameters of the method call. The constructors supported in DeeDS are conjunction, disjunction, sequence constructors, and predictable closure constructors in the recent and chronicle context [8, 6]. Further, events are either primitive or composite, where the former are assumed to be atomic and instantaneous [8]. Thus, primitive events are allowed to trigger critical time-constrained actions. The ECC, which is a submodule of the EMM, guarantees that events that triggers critical transactions are detected within an upper bound. The ECC continuously checks and computes the event input queue where incoming event instances are placed. Events are classi ed as critical or non-critical depending on the deadline criticality and importance of the action part of the rules associated with the events [3]. The scheduling module dynamically guarantees the deadlines of the transactions. The purpose of the scheduler is to nd a feasible schedule (a schedule such that the execution order of the transaction enforces the timeliness and timing requirements of the transactions are not violated) and guarantee critical tasks in presence of non-critical tasks in case of overloads. The scheduler interacts with a dispatcher residing on the application processor. The dispatcher starts and stops the execution of the transactions on the application processor. Timing constraints are represented with value functions, which are parameterized in order to reduce the storage requirements and the computational cost associated with calculating the value for a time point. The workload consists of periodic and non-periodic1 transactions with various criticality, where transactions are autonomous executable entities without precedence relationships. Associated with the critical transactions are contingency plans, which are alternative transactions requiring signi cantly less computational power but still providing a usable service (result). The strategy for resolving overload is to invoke the contingency plans and drop non-critical transactions in a controlled way, and thereby avoid jeopardizing the timeliness of the critical transactions.
3 PREDICTABLE EVENT DETECTION There is a de nite need for software engineering methods applicable to complex systems that allow the derivation of re ned design constraints from the properties of a particular systems architecture, to support the design of applications 1 Non-periodic critical transactions must be sporadic, i.e., their minimum inter-arrival time must be known.
Re ning Design Constraints in DeeDS
7
for that system. This derivation can be part of a re nement spiral of the requirements during prototyping [18], where the original design constraints are veri ed and re ned with the derived constraints. The result of this process may be to choose another system architecture or application design, or to negotiate the requirements for re nement purposes with the customer. One of the basic problems is to provide an active real-time database system with predictable critical system services for software engineers. In this section we provide the results from a study of di erent time-constrained interaction styles between the critical system services [16]. These critical system services are provided by the scheduler and the event monitor (see section 2.2). We assume it is possible to predict the worst-case execution time of the event detection algorithm given an event speci cation which contains no sources of unpredictability. That is, the event graph [8] speci ed by the event speci cation must not contains any cycles and all constructors must be bounded. Moreover, event triggered systems are prone to event showers [15], i.e., a burst of events during a short interval, which may be caused by a single physical event. In this work we assume that the environment is constrained to guarantee a minimum interarrival time between events (events are smoothed).
3.1 Interaction Model and Constraints In this section we will present a model for deriving the minimum interarrival time of events and their minimum delay, i.e., the unavoidable delay between the occurrence of an event and the earliest point in time after the event at which an associated transaction can be scheduled. First, an overall design, ensuring timely behavior of the critical system services assuming that the worst-case execution time estimates of the system service algorithms are correct, will be presented. Second, we will present the assumptions for our work. Furthermore, we will present formulas expressing the interaction periodicity of the event monitor and the scheduler. In DeeDS, the interaction between the scheduler and the event monitor is performed during xed periods of time, where the event monitor provides the scheduler with information. The scheduling and event monitoring must complete within this xed period of time. The interaction can either be synchronous, which implies that the event monitor and the scheduler work according to a static schedule in a time-triggered way, i.e., they are invoked at prespeci ed instants de ning the start of a time slot [15]; or asynchronous,
8
Chapter 1
which implies that the event monitor preempts the scheduler and executes whenever an event occurs, i.e., in an event-triggered way [15]. When the event monitor executes it uses a time slot of prespeci ed length in the period, however, in the asynchronous interaction style the start of this time slot is not predetermined.
Principal Design of the Interaction The principal design of the interaction is based on a xed-priority scheme with arbitrary preemption supported by most real-time operating systems, e.g., OSE Delta. Moreover, support by hardware timers is desirable, because the time base granularity needed is often too close to what most operating systems can provide accurately and eciently. In the synchronous interaction style the scheduler and the event monitor is invoked at xed points relative to a period according to a xed schedule. In the design of the asynchronous interaction style a process each is needed for the scheduler and the event monitor respectively, because the event monitor must be able to preempt the scheduler. For predictability reasons the periods and, hence, the execution of the scheduler and event monitor are strictly enforced. It is possible to choose interaction style when con guring the system. The scheduler rst executes the minimum part of the scheduling algorithm to get a sucient schedule, i.e., a schedule which meets the minimum requirements for a schedule. For example, given a set of hard and soft deadline transactions the sucient schedule could be that all hard deadlines and an average of 90 percent of the soft deadlines are met. After that it may perform re nements loops if there is enough time left in the period, which particularly is a possibility in the asynchronous interaction style. The reason is that if the remaining time before the end of the period is less than the worst-case execution time of the event monitor the scheduler may use the remaining time instead. In the asynchronous interaction style is is assumed that it is possible to provide additional information to the scheduler during the execution of the scheduler in a period if an incremental scheduling algorithm is used. At the end of the period the schedule is passed to the dispatcher.
Basic Assumptions and Variable De nitions Let TSndt be the necessary decision time of the scheduling algorithm itself, i.e., the execution time it takes to get a sucient schedule which meets the
Re ning Design Constraints in DeeDS
9
requirements. Let Tplan be the time that the scheduler plans ahead, i.e., there exists a schedule for the interval starting when the scheduler nishes (tSfinish ) and ending at tSfinish + Tplan .2 The assumption is that Tplan is larger than TSndt in order to be useful. All desired primitive and composite event types are assumed to be known a priori and, as there are no cycles in an event graph, the worst-case execution time of event detection is assumed to be known. Let TEwcet be the worst case execution time for the event detection algorithm, i.e., the time it takes for the event detector to consume an event instance, possibly compose, and disseminate the resulting event instances3 . It is assumed that TEwcet
