Refining Design Constraints using a System Services ...

1

Re ning Design Constraints using a System Services Model of a Real-Time DBMS Jonas Mellin, Jorgen Hansson, and Sten F. Andler Department of Computer Science, University of Skovde Box 408, S-541 28 Skovde, Sweden email: fjonas,jorgen,[email protected]

Abstract | In the DeeDS prototype, active database functionality and critical timing constraints are combined with integrated monitoring techniques. In the scope of DeeDS, this paper presents a mathematical model which is used to derive two important design constraints; worst-case minimum delay and maximum frequency of events. This model is based on a dual-processor hybrid-monitoring solution. Furthermore, dierent interaction styles between the scheduler and the event monitor are evaluated.

I. 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, computed by the real-time system, to a certain event/situation detected by a sensor. In other words, the real-time system reacts, and this reactive behavior can be modeled by an active database. We are currently building a DeeDS (Distributed Active Real-Time Database System) prototype [1], [2]. DeeDS is an event-triggered real-time database system, using dynamic scheduling of a set of transaction types of mixed criticality (i.e., transactions with 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]. 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 paper focuses on some important design constraints imposed by the critical system services in the DeeDS prototype.

There is a de nite need for methods that allow the derivation of re ned design constraints from the properties of a particular systems architecture, to support the design of applications for that system. This derivation can be part of a re nement spiral of the requirements, 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 change the requirements if possible. Particularly for complex systems, e.g., systems which might use an active real-time DBMS, such methods are strongly desirable. Given a exible derivation method, it is possible to check whether a particular application on a given system will meet its requirements, e.g., whether it will be able to respond in 5 ms to a critical event, under a maximum load of 30 schedulable transactions (with partly known timing requirements) at any moment and a maximum of 1000 events/second. Moreover, given that the method is suf ciently general, two architectures may be compared and evaluated. In this work we present a model (for our purposes, a basis for a derivation method) for analyzing the system properties that will allow us to derive two important design constraints, namely maximum frequency of events, and worst-case minimum delay. The model takes into account primitive and composite events, event showers, dynamic scheduling of mixed transaction types, and hybrid monitoring. This work is part of the veri cation and validation of the DeeDS prototype, where the predictability of the system is the most important factor. The rest of this paper is structured as follows: In section II we give a short description of the DeeDS architecture and its components. In section III a detailed problem de nition is speci ed for providing predictable system services. In section IV the basic interaction model between the scheduler and the event monitor is presented, and the demonstration of the correctness and usefulness of the model is discussed along with some preliminary results. In section V related work is presented, and, nally, in section VI we give our conclusions and future work. II. DeeDS Architecture

The DeeDS architecture is mainly layered where the lay-

This work was supported by NUTEK (The Swedish National Board for Industrial and Technical Development) and the Ministry of Edu- ers are tightly coupled, i.e., they use the procedure calls for cation and Science in Sweden interlayer communication and the layers can access neces-

2

Real-time applications

DeeDS Services Rule manager Event monitor Event Criticality Checker OBST on other nodes

OBST object store

Replication and concurrency

Scheduler

tdbm storage manager

Dispatcher OSE Delta + Extended file system Application Processsor

OSE Delta Services Processor

Loose coupling Tight coupling Distributed communication

Fig. 1. The DeeDS architecture

sary information about each others internal state. Moreover, the architecture of DeeDS is divided into applicationrelated functions and critical system services. The application-related functions are decomposed into: the rule manager module (RMM), the object store (OBST) [7], and the storage manager (tdbm) [5]. These application-oriented modules are layered. Critical system services consist of scheduling, event criticality checking, and event monitoring (EMM) provided by the service module. By replacing the storage manager in OBST with tdbm, nested transactions will be supported [14]. Main memory residency of the rst version of the database system will be provided by existing main memory resident le systems of OSE Delta[15]. The scheduler controls all layers and the event monitor services the layers. The service module works at all layers, where the application-related modules are loosely coupled with the service module. DeeDS uses a dual processor hybrid-monitoring solution, e.g., one processor is dedicated for monitoring another processor which executes a software instrumented application [11]. The critical system services (scheduling and event monitoring) execute on a dedicated processing element named service processor. Application related functions execute on a dierent processing element named the application processor. Both processors execute a distributed

real-time kernel (OSE Delta) providing both application related tasks and system services a generic interface to the hardware. The assignment of separate functionality to dedicated processors, ( g. 1), gives us advantages when predicting the behavior because application tasks do not use processor time on the service processor, and vice versa. Hence, the system services are less dependent on the application transaction execution, which simpli es our model. Furthermore, it makes it possible to use milestones to measure progress of application tasks [12]. Rule Manager Module (RMM): RMM provides rule storage, rule selection, condition evaluation. DeeDS uses an extended form of ECA-rules considering the timing constraints. Events are detected by the event monitor module and are then forwarded to the RMM as event instances. The rules that are associated with that event will be selected. The condition part of the rules is then evaluated to determine whether the action should be executed or not. However, the RMM does not carry out action execution. Instead, as the action becomes executable, the RMM passes information about the action to the scheduler, possibly as an event instance. Event Monitoring Module (EMM): The EMM delivers event instances to the interested recipients upon the detection within a bounded time. Event graphs performing parameter computation is used for detecting events and

3

composing events instances [8]. The event instances carry information about event type, time of occurrence, and the scope, e.g., transaction, in which it was generated. 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 allowed to trigger time-constrained actions. Event Criticality Checker (ECC): The ECC 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 events 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 [4], i.e., the ECC prioritizes critical events, in front of non-critical events. Scheduling Module: The schedule module dynamically guarantees the deadlines of the transactions. The purpose of the scheduler is to nd a feasible schedule and guarantee critical tasks in presence of non-critical tasks in case of overloads. The scheduler will interact with a dispatcher residing on the application processor. The dispatcher will start and stop the execution of the transactions on the application CPU. 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 critical transactions. Replication and Concurrency Control Module: In order to enforce predictability in DeeDS, the following design decisions have been made to isolate unpredictable delays due to disk accesses, network communication and distributed commit processing. First, the database is main memory-resident. Second, the database is fully replicated, i.e. each node will have a copy of the entire database. Third, lazy replication is used when propagating updates of the database, implying that temporary inconsistencies may arise and must be tolerated by applications. III. Problem Definition

The basic problem is to provide an active real-time database system with predictable critical system services. In this paper we study dierent time-constrained interaction styles between the critical system services provided by the scheduler, which is needed to meet deadlines, and the

event monitor, which is needed in any complex real-time system such as an active real-time DBMS. Events, which are atomic and instantaneous [8], are represented by event instances in the system. Primitive events are prede ned elementary occurrences from the system, environment, or the application; whereas composite events are composed out of primitive or composite events based on an event algebra using constructors such as \and", \or", \sequence", or \closure constructors" [9], [6]. An event is detected when the event instance is disseminated from the event monitor, which executes the event detection algorithm, to interested recipients, e.g., the rule manager in an active DBMS. It is assumed that it is possible to predict the event detection algorithm given an event speci cation (consisting of what event types are required by which recipient), by restricting the closure constructors and using event graphs [8] (constrained so that they do not contain cycles) for event detection. Event triggered systems are prone to event showers [13], i.e., a burst of events with during a short interval which may be caused by a single physical event. There are two general solutions to this problem [13]; i) smoothing, i.e., to constrain the environment to guarantee a minimum interarrival time between events (so-called sporadic events); and ii) ltering, i.e., redundant events are removed. In this work it is assumed that events are smoothed and ltered before they arrive to the event monitor. As mentioned before, dynamic scheduling is adopted in DeeDS. By monitoring the progress of execution of transactions, and sending reports to the scheduler when milestones within transactions are reached, the scheduler will gain increased knowledge about the real execution time as opposed to the worst-case execution time which was used for making the original scheduling decisions. Hence, by using this information, better usage of system resources can be achieved.2 IV. Interaction Model and Constraints

In this section we will present a model for deriving the maximum frequency of events and their minimum delay or earliest release time (i.e., the unavoidable delay between the occurrence of an event and the earliest point in time after the event that an associated transaction can be scheduled). First, we will present the basis and the assumptions for our work. Further, we will de ne formulas de ning the interaction periodicity of event monitor and scheduler. In addition we present actual estimated results based on measurements. 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

2 Further, by constant monitoring of the progress of the execution, Non-periodic critical transactions must be sporadic, i.e., their min- the system can detect when a transaction is not making any progress, imum inter-arrival time must be known. which could arise in certain situations depending on the system state. 1

4

schedule in a time-triggered way, i.e., they are invoked at pre-speci ed instants de ning the start of a time slot [13] ( g. 2); or asynchronous | which implies that the event monitor preempts the scheduler and executes whenever an event occurs, i.e., in an event-triggered fashion [13] ( g. 3). When the event monitor executes it uses a time slot of pre-speci ed length in the period, however, in the asynchronous interaction style the start of this time slot is not pre-determined. An overall design, ensuring that the periods are strictly kept assuming that the worst-case execution time estimates of the system service algorithms are correct, is presented below. It is assumed that events are smoothed so that a maximum of NE events are presented to the event monitor during one period. Period n

Event Detection

Period n+1

Period m

Scheduler

Fig. 2. Example of synchronous interaction.

Period n

Event Detection

Period n+1

Period m

Scheduler

Fig. 3. Example of asynchronous interaction.

A. Principal Design of the Interaction The principal design ( g. 4) of the interaction is based on a xed-priority scheme with arbitrary preemption supported by most real-time operating systems, e.g., OSE Delta. The synchronous interaction style is designed as a cyclic executive invoking the scheduler and the event monitor respectively, which can be designed as one process invoking the event monitor and the scheduler as functions in a loop or two processes executing 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. In order to make it possible to test dierent designs the event monitor and the scheduler is designed and implemented as functions, which are called by a process or processes. For predictability reasons the periods and, hence, the execution of the scheduler and event monitor are strictly enforced by a conductor. The conductor mainly works like a dispatcher. Moreover, the conductor keeps track of how much time has been used in a period (using hardware timers causing hardware interrupts) and, hence, the

number of event monitoring slots there are left for both interaction styles. In the synchronous interaction style the conductor signals the scheduler to start in the beginning of the period, whereas it signals the scheduler to start after all no event monitoring slots are left in the synchronous interaction style. In addition the conductor must reinitialize the amount of events the event monitor may consume at the start of each period. In the asynchronous interaction style there is a possibility for the scheduler to use the last slot, originally meant for event monitoring, for re nement loops. There are two dierent designs for the event monitoring function depending on the interaction style. In the synchronous interaction style the outline of the algorithm is as follows: 1. wait for signal from conductor 2. otherwise consume an event instance if there is one 3. return a value to the calling process that makes it call the event monitoring function if there are slots left In the asynchronous interaction style the outline of the algorithm is as follows: 1. check if the reason for the invocation is a signal from the conductor and, if that is the case, reduce the amount of events the event monitor can consume 2. if the reason for the invocation is an event, consume it If the event monitor is allowed to consume an event instance it calls the event composition algorithm, which detects, composes and disseminates event instances to the subscribers. The subscribers are assumed to be other processes. The scheduler function 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 according to the conductor. In the asynchronous interaction style is is assumed that it is possible to insert a new task into the schedulable task set if an incremental scheduling algorithm is used. At the end of the period the schedule is passed to the dispatcher, which dispatches the scheduled transactions. The conductor is designed and implemented as an interrupt process, i.e., a process that is woken up to serve an interrupt or, as is the case in OSE Delta, when receiving a message or the fast semaphore3 of the process is signaled. B. Basic Assumptions 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 requirements. Let Tplan be the time that the scheduler plans ahead, i.e., there exists a schedule for the interval starting when the scheduler 3 A fast semaphore is equivalent to a general semaphore in all aspects but only the owning process can wait on it

5

C.2 Maximum Frequency of Events and Worst-case Minimum Delay The maximum frequency of events for the synchronous interaction style is fsmax = NE =TPs (minimal interarrival Conductor Event monitor time TIsmin = TPs =NE ) to allow a maximum of NE events during a period. For the asynchronous interaction style the formula is famax = NE =TPa (TIamin = TPa =NE ). The worst-case minimum delay TDsmin for synchronous Dispatcher Scheduler interaction is: TPs + TSndt + TEwcet (3) Fig. 4. Principal design of the interaction. The rationale is that an event that occurs during the last execution of the event monitor in period n is not consumed until the next time the event monitor executes, i.e., in pe nishes (tSfinish ) and ending at tSfinish + Tplan .4 The as- riod n + 1. Thus, the earliest time that the associated sumption is that Tplan is larger than TSndt in order to be transaction of the event can be scheduled is during period useful. n + 2 ( g. 5). All desired primitive and composite event types are assumed to be known a priori and, as there are no cycles in an Period n Period n+1 event graph, the worst-case execution time of event composition 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 Worst case min delay instance, possibly compose, and disseminate the resulting event instances5. It is assumed that TEwcet