Embed Size (px)
Citation preview
Master’s Thesis
Adaptive QoS Management inDynamically Reconfigurable Real-Time
Databases
byDaniel NilssonHenrik Norin
LITH-IDA-EX–05/014–SE
2005-02-16
i
Master’s Thesis
Adaptive QoS Management in DynamicallyReconfigurable Real-Time Databases
by Daniel Nilsson
Henrik Norin
LiTH-IDA-EX–05/014–SE
Supervisor: Aleksandra TesanovicMehdi AmirijooDepartment of Computer and InformationScienceat Linkopings University
Examiner: Dr. Jorgen HanssonDepartment of Computer and InformationScienceat Linkopings University
Abstract
During the last years the need for real-time database services has increaseddue to the growing number of data-intensive applications needing to enforcereal-time constraints. The COMponent-based Embedded real-Time data-base (COMET) is a real-time database developed to meet these demands.COMET is developed using the AspeCtual COmponent-based Real-timesystem Development (ACCORD) design method, and consists of a numberof components and aspects, which can be composed into a number of differ-ent configurations depending on system demands, e.g., Quality of Service(QoS) management can be used in unpredictable environments.
In embedded systems with requirements on high up-time it may not bepossible to temporarily shut down the system for reconfiguration. Insteadit is desirable to enable dynamic reconfiguration of the system, exchangingcomponents during run-time. This in turn sets demands on the feedbackcontrol of the system to adjust to these new conditions, since a new timevariant system has been created.
This thesis project implements improvements in COMET to create amore stable database suitable for further development. A mechanism fordynamic reconfiguration of COMET is implemented, thus, enabling com-ponents and aspects to be swapped during run-time. Adaptive feedbackcontrol algorithms are also implemented in order to better adjust to work-load variations and database reconfiguration.
Keywords: real-time databases, dynamic reconfiguration, quality of ser-vice, component-based software development, aspect-oriented soft-ware development, adaptive feedback control
v
Sammanfattning
Se senaste aren har behovet av realtidsdatabastjanster okat p.g.a. detokande antalet dataintensiva applikationer vilka behover uppfylla tidskrit-iska krav. COMponent-based Embedded real-Time database (COMET) aren realtidsdatabas utvecklad for att tillmotesga dessa krav. COMET arutvecklat enligt AspeCtual COmponent-based Real-time system Develop-ment (ACCORD) designmetoden och bestar av ett antal komponenter ochaspekter, vilka kan sattas samman till ett antal konfigurationer beroendepa systemkrav, t.ex. kan kvalitetsgaranti anvandas i oforutsagbara miljoer.
I inbyggda system, med krav pa hog tillganglighet, kan det vara omoj-ligt att tillfalligt stanga ner systemet for omkonfiguration. Istallet ar detonskvart att mojliggora dynamisk omkonfiguration av systemet, d.v.s. bytaut komponenter under exekvering. Detta staller i sin tur krav pa aterkop-plingen av systemet eftersom ett nytt tidsvariant system har skapats.
Detta examensarbete implementerar forbattringar av COMET for attskapa en mer stabil databas battre lampad for fortsatt utveckling. Enmekanism for dynamisk omkonfiguration av COMET implementeras ochpa sa satt mojliggor byte av komponenter och aspekter under exekvering.Algoritmer for adaptiv aterkoppling implementeras ocksa for att battrekunna anpassa aterkopplingen till andringar i arbetslast och omkonfigura-tion av databasen.
vii
Acknowledgements
The authors would first of all like to thank each other for good cooperationduring this master thesis project. Although we have spent an unhealthyamount of time together we are still alive and friends. We would also liketo thank our supervisors Aleksandra Tesanovic and Mehdi Amirijoo. Ithas been a great experience working together with you. Your input andencouragement kept our motivation up and our anger level down. We couldnot have wished for better supervisors. Thank you very much for makingour master thesis project into a productive and fun six months. We wishyou all of the best in the future. We would also like to send a thank youto our examiner Dr. Jorgen Hansson and hope that your workload willdecrease in the future. Calin, sorry for being the loudest students you haveever met. Unfortunately for you we got the room next to you. Thank youalso to the rest of the staff at RTSLAB. Sorry we did not have time toattend the lab meetings.
ix
Contents
1 Introduction 51.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Target Reader . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Background 72.1 Real-Time Systems . . . . . . . . . . . . . . . . . . . . . . . 72.2 Real-Time Databases . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Data Model . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Transaction Model . . . . . . . . . . . . . . . . . . . 9
2.3 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Programming Methods . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Component-Based Software Development . . . . . . 112.4.2 Aspect-Oriented Software Development . . . . . . . 11
2.5 ACCORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.1 RTCOM . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 COMET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6.1 COMET components . . . . . . . . . . . . . . . . . 142.6.2 COMET aspects . . . . . . . . . . . . . . . . . . . . 15
2.7 Control Theory . . . . . . . . . . . . . . . . . . . . . . . . . 162.7.1 PID-control . . . . . . . . . . . . . . . . . . . . . . . 162.7.2 Performance Metrics . . . . . . . . . . . . . . . . . . 17
2.8 Feedback Control Algorithms . . . . . . . . . . . . . . . . . 192.8.1 FC-U . . . . . . . . . . . . . . . . . . . . . . . . . . 19
CONTENTS
2.8.2 FC-M . . . . . . . . . . . . . . . . . . . . . . . . . . 202.8.3 FC-UM . . . . . . . . . . . . . . . . . . . . . . . . . 202.8.4 QMF . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 Adaptive Control Theory . . . . . . . . . . . . . . . . . . . 212.9.1 Self-Tuning Regulator Control . . . . . . . . . . . . 212.9.2 Least Squares And Regression Models . . . . . . . . 23
3 Problem Description 273.1 COMET Improvements . . . . . . . . . . . . . . . . . . . . 27
3.1.1 COMET Merging . . . . . . . . . . . . . . . . . . . . 273.1.2 COMET Deficiencies . . . . . . . . . . . . . . . . . . 28
3.2 Dynamic Reconfiguration . . . . . . . . . . . . . . . . . . . 293.3 Adaptive Feedback Control . . . . . . . . . . . . . . . . . . 30
3.3.1 Adaptive Feedback Control Algorithms . . . . . . . 303.3.2 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Aim and Objectives . . . . . . . . . . . . . . . . . . . . . . 31
4 Advanced Preliminaries 334.1 COMET Components . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 User Interface Component (UIC) . . . . . . . . . . . 344.1.2 Scheduler Manager Component (SMC) . . . . . . . . 354.1.3 Transaction Manager Component (TMC) . . . . . . 364.1.4 Locking Manager Component (LMC) . . . . . . . . 364.1.5 Indexing Manager Component (IMC) . . . . . . . . 364.1.6 Memory Management Component (MMC) . . . . . . 36
4.2 Transaction Flow . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Aspect Packages . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Concurrency Aspects . . . . . . . . . . . . . . . . . . 394.3.2 QoS Aspects . . . . . . . . . . . . . . . . . . . . . . 40
5 COMET Improvements 435.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3 Merging Into COMET v3.0 . . . . . . . . . . . . . . . . . . 465.4 Testing COMET v3.0 . . . . . . . . . . . . . . . . . . . . . 465.5 COMET API . . . . . . . . . . . . . . . . . . . . . . . . . . 52
xi
5.5.1 COMET Without Concurrency and QoS . . . . . . . 525.5.2 COMET With Concurrency and QoS . . . . . . . . 53
5.6 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.7 Coding and Naming Standard . . . . . . . . . . . . . . . . . 57
5.7.1 Components . . . . . . . . . . . . . . . . . . . . . . 585.7.2 Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 595.7.3 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.8 Tuple Updates and Deletions . . . . . . . . . . . . . . . . . 625.9 ACCORD and RTCOM Conformance . . . . . . . . . . . . 635.10 Data Passing . . . . . . . . . . . . . . . . . . . . . . . . . . 635.11 Building COMET and Generating Documentation . . . . . 64
6 Dynamic Reconfiguration 656.1 Requirements for Dynamic Reconfiguration . . . . . . . . . 65
6.1.1 Existing Models . . . . . . . . . . . . . . . . . . . . 666.2 Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.3 ACCORD and RTCOM Revisited . . . . . . . . . . . . . . 69
6.3.1 Requirement Conformance . . . . . . . . . . . . . . 716.4 Dynamic Reconfiguration of COMET . . . . . . . . . . . . 72
6.4.1 COMET Component Framework . . . . . . . . . . . 736.4.2 Component Changes . . . . . . . . . . . . . . . . . . 746.4.3 Aspect Changes . . . . . . . . . . . . . . . . . . . . 776.4.4 COMET Safe State . . . . . . . . . . . . . . . . . . 806.4.5 Saving Component States . . . . . . . . . . . . . . . 81
7 Adaptive Feedback Control 857.1 Adaptive QoS Configurations . . . . . . . . . . . . . . . . . 857.2 Adaptive Feedback Control Design . . . . . . . . . . . . . . 86
7.2.1 Self Tuning Regulator Control . . . . . . . . . . . . 867.2.2 Least Squares and Regression Models . . . . . . . . 90
8 Performance Evaluation 998.1 Experiment Setup . . . . . . . . . . . . . . . . . . . . . . . 1008.2 Execution Time Measurements . . . . . . . . . . . . . . . . 1018.3 Feedback Control Performance . . . . . . . . . . . . . . . . 103
8.3.1 Tuning Experiment . . . . . . . . . . . . . . . . . . . 104
CONTENTS
8.3.2 Load Experiment . . . . . . . . . . . . . . . . . . . . 1068.3.3 Transient Performance Experiment . . . . . . . . . . 106
8.4 Sampling Periods . . . . . . . . . . . . . . . . . . . . . . . . 1098.5 Self Tuning Regulator . . . . . . . . . . . . . . . . . . . . . 1118.6 Dynamic Reconfiguration . . . . . . . . . . . . . . . . . . . 114
8.6.1 Increasing Transaction Execution Time . . . . . . . 1148.6.2 Decreasing Transaction Execution Time . . . . . . . 118
8.7 Changing Controller Parameter Value . . . . . . . . . . . . 1228.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
9 Summary 1259.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 128
A Abbreviations 131
B Terminology 133
C Variables 135
D Test Runs 137D.1 Test Runs in COMET v3.0 . . . . . . . . . . . . . . . . . . 137D.2 Test Runs with QoS Management Aspects . . . . . . . . . . 138
E Division of Workload 141
1
List of Tables
5.1 COMET v2.0 Changes . . . . . . . . . . . . . . . . . . . . . 445.2 Component changes during COMET improvements . . . . . 475.3 Cont. Component changes during COMET improvements . 485.4 Aspect changes during COMET improvements . . . . . . . 495.5 Cont. Aspect changes during COMET improvements . . . . 505.6 Variables to set in the DBTrans and UIC_ SystemParamet-
ers structs when using aspect packages . . . . . . . . . . . 545.7 Debug functions available in COMET . . . . . . . . . . . . 555.8 Debug levels available in COMET . . . . . . . . . . . . . . 56
6.1 Basic Requirements for Dynamic Reconfiguration . . . . . . 67
8.1 Execution times for transactions running in COMET con-figured with HP2PL and MRFC . . . . . . . . . . . . . . . 101
8.2 Execution times of swapping components during dynamicreconfiguration of COMET with single transactions running 102
8.3 Execution times of swapping components during dynamicreconfiguration of COMET with a 300% load . . . . . . . . 103
8.4 The linear and quadratic difference in deadline miss ratio forthe closed-loop system using different sampling periods1 . . 111
8.5 The linear and quadratic difference in deadline miss ratio forthe open-loop system using different sampling periods1 . . . 112
8.6 The linear and quadratic difference in deadline miss ratiowhen delays are introduced . . . . . . . . . . . . . . . . . . 116
LIST OF TABLES
8.7 The linear and quadratic difference in deadline miss ratiowhen delays are introduced . . . . . . . . . . . . . . . . . . 120
8.8 The linear and quadratic difference in deadline miss ratiousing MRFC and varying controller parameter . . . . . . . 123
E.1 Description of project phases . . . . . . . . . . . . . . . . . 142E.2 Tasks performed by Daniel Nilsson . . . . . . . . . . . . . . 143E.3 Tasks performed by Henrik Norin . . . . . . . . . . . . . . . 144
3
List of Figures
2.1 An example of an aspect written in AspectC++ . . . . . . 122.2 A schematic view of a open-loop system . . . . . . . . . . . 162.3 A schematic view of a closed-loop system . . . . . . . . . . 172.4 Definition of settling time (T ) and overshoot (M) . . . . . . 182.5 Estimation of u(k) . . . . . . . . . . . . . . . . . . . . . . . 23
4.1 COMET components and their relations . . . . . . . . . . . 344.2 The execution steps of a transaction in COMET . . . . . . 38
6.1 Extended ACCORD with support for dynamic reconfiguration 696.2 Architecture of COMET Component Swapping . . . . . . . 73
7.1 Software composition of QoS aspects . . . . . . . . . . . . . 867.2 Architecture of adaptive feedback control using a self tuning
regulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907.3 Architecture of adaptive feedback control using a regression
model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.1 The average deadline miss ratio as a function of load for theopen-loop system . . . . . . . . . . . . . . . . . . . . . . . . 105
8.2 The average deadline miss ratio as a function of load for theclosed-loop system . . . . . . . . . . . . . . . . . . . . . . . 107
8.3 Transient behavior of COMET with MRFC applied . . . . . 1088.4 Transient behavior of COMET with MRFC applied using
different sampling periods . . . . . . . . . . . . . . . . . . . 110
LIST OF FIGURES
8.5 Performance of STRA G estimation . . . . . . . . . . . . . 1138.6 Deadline miss ratio when delays are introduced in the open-
loop system . . . . . . . . . . . . . . . . . . . . . . . . . . . 1158.7 Deadline miss ratio when delays are introduced and MRFC
is applied . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1168.8 Deadline miss ratio when delays are introduced and STRC
is applied . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178.9 Deadline miss ratio when delays are removed in the open-
loop system . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198.10 Deadline miss ratio when delays are removed and MRFC is
applied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1208.11 Deadline miss ratio when delays are removed and STRC is
applied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5
Chapter 1
Introduction
This chapter provides the motivation for this thesis (section 1.1). Further-more it presents the target reader (section 1.2) and an outline (section 1.3)of the thesis.
1.1 Motivation
During the last years the need for real-time database services has increaseddue to the growing numbers of data-intensive applications needing to en-force real-time constraints. Many of these applications also run in environ-ments with unpredictable workloads. By monitoring system performanceand applying control theory it is possible to adapt system behavior, thus,conform to the actual workload and guarantee a certain quality of ser-vice [5].
Another trend within software development and especially within real-time system development is the need for more configurable systems, de-pending on, e.g., application type or scarce resources. Component-basedsoftware development [30] combined with aspect-oriented software develop-ment [13], using a design method called ACCORD [33], can fulfill this need.A COMponent based Embedded real-Time database system (COMET) hasbeen developed using ACCORD enabling the possibility of reconfiguration
1.2. Target Reader
of real-time databases [33].An additional desire in systems with high up-time demands, is to be able
to swap the components constituting the system during run-time, thus, nothaving to initially shut down the system for recompilation. Due to com-ponent swapping and differences in performance of the component versions,this in turn would affect the systems composition and performance, pos-sibly leading to critical errors, when real-time constraints are no longerenforced. Using adaptive control techniques, it is possible to change howthe system is controlled, i.e., conforming control to the conditions of thechanged system. Thus, handling of component swapping and other timein-variances common to computer systems is made possible.
1.2 Target Reader
This thesis is intended for people with basic knowledge of computer science,control theory and mathematics. Areas where a deeper understanding isrequired are explained in the theoretical background chapter (Chapter 2).
1.3 Thesis Outline
The outline of the thesis is as follows. Chapter 2 provides the back-ground knowledge needed to understand the rest of the thesis. The problemdefinition is described in chapter 3, which also includes possible COMETimprovements, adaptive control algorithms, and a proposal for makingCOMET components swappable into the system during run-time. Chapter4 contains advanced preliminaries on COMET components and aspectpackages available. Descriptions of the merging of two COMET versionsand improvements implemented in COMET are found in chapter 5. Chapter6 provides requirements for dynamic reconfiguration, extensions to AC-CORD and RTCOM, and specifications on the implementation of dynamicreconfiguration in COMET. The design and implementation of the adapt-ive feedback control algorithms is described in chapter 7. In chapter 8the performance evaluation of the adaptive feedback control algorithms isdescribed. Finally a summary of the thesis is given in chapter 9.
7
Chapter 2
Background
This chapter introduces theory and defines concepts needed for good un-derstanding of the rest of the thesis. The firsts sections describe real-timesystems and real-time databases. In the proceeding sections, component-based and aspect-oriented software development is presented along with theACCORD design method, the RTCOM component model and the COMETdatabase platform are presented. Finally control theory and feedback al-gorithms conclude this chapter.
2.1 Real-Time Systems
There are many definitions of what exactly a real-time system (RTS) is.One quite general definition is [18]:
Any system where a timely response by the computer to ex-ternal stimuli is vital is a real-time system.
In other words a RTS is a system where not only the content of the response,but also the time in which it is provided, is of importance. An exampleof a RTS is a system in control over the cooling at a nuclear power plant,where actions taken are time critical, otherwise causing a core meltdown.
Tasks in a real-time system have deadlines stating when a task mustbe completed. Depending on the type of system and its application there
2.2. Real-Time Databases
exists three categories of real-time systems [18]. Hard real-time systems,e.g., systems controlling an aircraft, do not allow deadlines to be violated,as it can have catastrophic consequences. Soft real-time systems, e.g., mul-timedia streaming, allow deadline violations and degrading performancebut without anything catastrophic happening. In firm real-time systemsdeadlines can be missed, but no benefit is given from continuing executionof a task after the deadline is missed.
Multiple tasks are often running simultaneously in a RTS. A problemthat exists when trying to enforce the task deadlines is scheduling , i.e.,deciding in which order the tasks should execute. Tasks can either bescheduled off-line (static scheduling) or during run-time (dynamic schedul-ing). Several algorithms for dynamic scheduling exist [7], e.g., EarliestDeadline First (EDF), where the task with the deadline closest in time willhave precedence, and Rate Monotonic Scheduling (RMS), where tasks areassigned priorities based on their periods. A shorter period means higherpriority and, hence, higher precedence. EDF is sensitive to overload prob-lems. As long as the system is not overloaded, the system works optimally.As soon as the system gets overloaded, a domino effect may cause verymany transactions to miss their deadlines [7]. Often the worst-case exe-cution time (WCET), meaning the maximum time it takes to complete atask, is used for estimating how long a task will take to execute.
Many real-time systems, called embedded systems, are used to controlphysical devices like airplanes, nuclear reactors etc. These systems oftenhave limited CPU and memory, thus placing demands on the RTS to useresources, e.g., memory and CPU, efficiently [7].
2.2 Real-Time Databases
Real-time databases (RTDB) [18] are integrated in many data intensiveapplications, e.g., banking and stock market systems. Although similarto traditional database systems, there are some additional requirementson a RTDB [18]. Firstly, queries made to the RTDB have soft- or harddeadlines that must be enforced, i.e., the system response times must bepredictable. Secondly, there are additional consistency demands on theRTDB. Absolute consistency is a measurement of accuracy, meaning that
9
data in the database should reflect the environment, e.g., when data isread from a sensor. A RTDB is thus dealing with temporal data, i.e., datathat is not valid after a certain amount of time. Data objects can bedivided into base data objects, i.e., data object containing a view of thereal-world environment, and derived data objects obtained from base dataobjects [25]. Relative consistency means that data objects, used to producea certain derived data object, must be updated relatively close to each otherin time [18].
2.2.1 Data Model
In this thesis we consider only base data objects. The following attributesare attached to a data object di:
• TSi, the time stamp of the latest update.
• AV Ii, the absolute validity interval of di.
A data object di is considered to be fresh, as opposed to stale, if
CurrentT ime ≤ TSi +AV Ii (2.1)
2.2.2 Transaction Model
Tasks querying and writing to the RTDB are called transactions, whichare atomic units of work, i.e., they are either performed completely or notdone at all [18]. In COMET, a transaction, τi, is classified as one of twotypes:
• User transactions arrive from the application programs and can readbase data objects and write to derived data objects. These transac-tions arrive aperiodically.
• Update transactions are write transactions that update the base dataobjects. These transactions arrive periodically.
By lowering the update rate of the data, reflecting the environment, we geta less absolute consistent system, but more resources for user transactionsand vice versa.
A transaction, τi, in the database system has the following attributes:
2.3. Quality of Service
• EEi, the estimated execution time of τi.
• AEi, the actual execution time of τi.
For periodic tasks, i.e., update transactions, we additionally define:
• Pi, the invocation period of τi.
• Di, the relative deadline of τi. We set Di = Pi,∀i.
• EUi, the estimated CPU utilization of τi, EUi = EEi/Pi.
• AUi, the (actual) CPU utilization of τi, AUi = AEi/Pi.
For aperiodic tasks, i.e. user transactions, we additionally define:
• AI, the average inter-arrival time of τi.
• Di, the relative deadline of τi. We set Di = AI,∀i.
• EUi, the estimated CPU utilization of τi, EUi = EEi/EIi.
• AUi, the (actual) CPU utilization of τi, AUi = AEi/AIi.
2.3 Quality of Service
Quality of Service (QoS) refers to the idea that utilization, miss ratio, andother characteristics in a RTDB can be measured and improved. There areseveral ways to deal with QoS demands, e.g., through resource reservationor admission control [31], i.e., rejecting user transactions in a RTDB [5],to enforce the QoS requirements. It is also possible for a system to haveseveral QoS levels [20] and deliver a more imprecise result with lower QoS,meaning acceptable results that require less resources, e.g., computationtime, bandwidth or memory. An example of this is a multimedia streamingapplication that chooses to stream lower quality media when bandwidth islow [9].
11
2.4 Programming Methods
This section covers two programming methods, component-based softwaredevelopment (CBSD) and aspect-oriented software development (AOSD),that have developed in the last years to lower costs and enforce reusabilityand tailorability of software.
2.4.1 Component-Based Software Development
Component-based software development has been developed to lower costsand achieve a higher level of reuse and reliability in software develop-ment [30]. CBSD evolves around the concept of composing pre-definedsystems out of components. A component is a unit of composition withspecified interfaces and explicit context dependencies only [30]. Interfacescan be considered as the components access points. These points allowclients of the components, e.g., other components or applications, to accessthe services of the components. There are three types of interfaces [6]:provided, required and configuration interfaces. The configuration inter-faces are intended for configuration of the components by the user com-posing the system. The provided and required interfaces are used whencomponents are combined with other components.
2.4.2 Aspect-Oriented Software Development
Aspect-oriented software development is a new programming methodologythat allows to capture and modularize concerns that crosscut a softwaresystem in so-called aspects [13]. Examples of such cross-cutting aspectsare memory optimization, concurrency control and error handling. AOSDimplementation of a software system consists of [33] (i) components writtenin a component language, e.g., C++ and Java, (ii) aspects, written in anaspect language, e.g., Aspect C++ [28], and (iii) an aspect weaver, whichis a special compiler for combining components and aspects in a processcalled aspect weaving .
Aspect languages use the concept of pointcuts, which are sets of joinpoints described by a pointcut expression. Join points are defined as pointsin the component code where aspects can be woven. The code that should
2.4. Programming Methods
run at the join points, specified by the pointcut expression, is specified inthe advice declaration. Advice can be declared as either before, after, oraround advice, specifying if the advice code should be executed, respect-ively, before, after or in place of the join points. An example of an aspectcan be seen in figure 2.1. Firstly, the pointcut mainExecution() is definedwhich corresponds to the join point int main() in the component code, i.e.,everywhere in the component the function main() is called with the returntype int. Secondly, two advice are declared. The first one prints Beforemain() before the join point corresponding to the pointcut mainExecu-tion() is executed, i.e., before int main() is executed in the componentcode. The second one prints After main() after the join point corres-ponding to the pointcut mainExecution() is executed. If this exampleaspect should be woven into a simple program, containing one main func-tion, the text Before main() would be printed when starting the program,and After main() would be printed just before the program terminates.
aspect BeforeAfterPrinter {
pointcut mainExecution() = execution(‘int main()’);
advice mainExecution() : before() {cout << ‘Before main()’ << endl;
}
advice mainExecution() : after() {cout << ‘After main()’ << endl;
}};
Figure 2.1: An example of an aspect written in AspectC++
13
2.5 ACCORD
By combining CBSD and AOSD in real-time system development, develop-ment of more configurable and tailorable software is possible. One designmethod for providing this is AspeCtual COmponent-based Real-time sys-tem Development (ACCORD) [33]. The design method consists of thefollowing:
• A decomposition process for decomposition of the real-time systeminto a set of components and into a set of aspects.
• Components, with well-defined functions and interfaces.
• Aspects, as properties cross-cutting the functionality of the system.
• A real-time component model (RTCOM) that describes a real-timecomponent, supporting aspects while also enforcing information hid-ing.
2.5.1 RTCOM
The RTCOM component model consists of three parts [33]:
• The functional part consists of the actual code implementing thecomponents functionality. Each component contains fine granularmethods or function calls called mechanisms and more coarse gran-ular operations available to other components or the system. Theoperations are implemented using the underlying mechanisms of thecomponent, and are flexible in the sense that their implementationcan be changed by applying different application aspects.
• The run-time system dependent part handles temporal behavior ofthe functional part of the component, e.g., WCET specifications.
• The composition part of RTCOM contains information about com-ponent compatibility with respect to both application aspects andother components.
The aspects in RTCOM can be divided into three types [33]:
2.6. COMET
• Application aspects tailor the components based on the underlyingapplication requirements.
• Run-time aspects contain the information describing the componentbehavior with respect to the target run-time environment.
• Composition aspects describe with which other components a com-ponent can be combined and handles versioning. Composition aspectscan also adapt components to work with other components.
2.6 COMET
To enable development of different database configurations for different em-bedded and real-time applications COMET (COMponent-based Embeddedreal-Time database) has been developed [33]. COMET has been developedusing the ACCORD design concept and the RTCOM component model.
2.6.1 COMET components
COMET has been divided into seven basic components with well-definedfunctions and interfaces:
• The User Interface Component (UIC) enables users to access data inthe database.
• The Scheduler Manager Component (SMC) provides mechanisms forperforming scheduling of transactions arriving to the system.
• The Locking Manager Component (LMC) provides locking of data,used to maintain concurrency and consistency.
• The Transaction Manager Component (TMC) coordinates the activ-ities of all components in the system with respect to transaction ex-ecution.
• The Indexing Manager Component (IMC) deals with indexing ofdata.
15
• The Memory Management Component (MMC) manages access todata in the physical storage.
• The Buffer Manager Component (BMC) manages buffers used whenrunning transactions.
A more detailed description of how COMET components are implementedis given in chapter 4.
2.6.2 COMET aspects
The decomposition of COMET into aspects, corresponding to the AC-CORD decomposition, concludes with three major classes of aspects, andseveral types of aspects belonging to those classes.
1. Run-time aspects
• Resource demand• Temporal constraints• Portability
2. Composition aspects
• Compatibility• Versioning• Flexibility
3. Application aspects
• Transaction• Real-time scheduling• Concurrency control• Memory optimization• Synchronization• Security
Since COMET is currently under development, the current implementationlacks many of the aspects COMET has been decomposed into. A more indetail description of implemented COMET aspects is given in chapter 4.
2.7. Control Theory
2.7 Control Theory
Control theory is used to give appropriate stimulus to a process or systemto make the process or system behave in a desirable manner. Typically, thesystem to control has a set of measurable output signals, yi, and a set ofinput signals, vi, that can be used to influence the system [12]. The controlproblem consists of making the system produce an output signal whichfollows a reference signal (r). If the output signals are not available whendeciding the input signals, defined as an open-loop system [12], a preciseknowledge of the input signals effect on the output signals is demanded.Driving a car blindfolded requires, e.g., exact knowledge of which directionthe car takes when turning the steering wheel [12]. A schematic view of aopen-loop system is shown in figure 2.2. On the other hand, if the outputsignal is used when deciding the input signal, called a closed-loop or feedbackcontrol system [12], only a very approximate understanding of the systemdynamics is required. In the car driving example it would be sufficient toknow that, e.g., turning the steering wheel clockwise would result in a rightturn. Fine adjustments could then be made to compensate for the differencebetween the output and reference signal, i.e., the error e = y − r [12]. Themain reason to use feedback control is to reduce uncertainty, which canbe, e.g., in the form of a modeling error in the system description [24]. Aschematic view of a closed-loop system is shown in figure 2.3.
r
v
ySystem
Open-loop system
Controller
Figure 2.2: A schematic view of a open-loop system
2.7.1 PID-control
The PID-controller is the most commonly used controller in a feedbacksystem, and its proportional (P), integral (I), and derivate (D) constitu-ents are basic to all controllers [24]. Each of these actions have a control
17
-1
yr
e vSystem
Closed-loop system
Controller
Figure 2.3: A schematic view of a closed-loop system
parameter associated to it. By varying these parameters the PID-controllerperforms differently. In the feedback control scheduling approach used inthis thesis, the integral part lies within the actuator. The derivate term isnot used at all, because derivate control may amplify the noise in miss ra-tio and utilization due to frequent workload variations in the unpredictableenvironment of a real-time system [20]. When the controller constitutesof only a proportional part, the manipulated variable v produced in thecontroller is computed as
v = Kp · e (2.2)
where Kp is the proportional controller parameter, and e is the error.
2.7.2 Performance Metrics
To analyze the performance of a feedback control system, some metricsmust be defined. The system designer specifies the desired behavior ofthe system with a performance specification based on transient and steadystate response [12].
Steady state appears when the controlled variable achieves a stablevalue. The transient response is studied in the time domain, typicallywhen a unit step is applied as input signal to the system [12]. The stepresponse given by the controlled variable can then be analyzed. Figure 2.4shows a typical step response. A number of performance metrics exist:
2.7. Control Theory
Time
Val
ue
TS
Mp
Reference
Figure 2.4: Definition of settling time (Ts) and overshoot (Mp)
• m(k), miss ratio, at the kth sampling instant is defined as:
m(k) = 100× #DeadlineMiss(k)#Terminated(k)
(%) (2.3)
where #DeadlineMiss(k) is the number of transactions that havemissed their deadline and #Terminated(k) as the number of termin-ated transactions over a sampling window ((k-1)T,kT), where T isthe sampling period . A desired target or reference level , MS , is setfor this metric.
• u(k), CPU utilization, at the kth sampling instant is the percentageof CPU busy time over a sampling window ((k-1)T,kT). A desiredtarget or reference level, US , is set for this metric.
• Ts, settling time, is the time it takes the systems transients to decayto a certain level.
19
• Mo and Uo, overshoot, is the maximum percentage the system over-shoots its miss ratio or utilization reference, i.e., Mo = (Mmax −MS)/MS , Uo = (Umax − US)/US .
2.8 Feedback Control Algorithms
Several feedback control algorithms exist for providing QoS managementin real-time databases [20]. While the FC-M (Feedback Control-Miss ra-tio) algorithm is currently implemented in COMET [5], FC-U (FeedbackControl-Utilization) and FC-UM (Feedback Control-Utilization and Missratio) are not.
2.8.1 FC-U
FC-U is a utilization control loop for controlling U(k) [20]. We define teu(k)as the total estimated CPU utilization, i.e, the estimated utilization of alltasks in the system in the kth sampling.
The control loop samples the utilization periodically, computes a changein the total estimated utilization, denoted dU (k), and adds it to teu(k),which is then used by an Actuator that admits a transaction, Tj , iff:
EUj +∑∀i
EUi ≤ teu(k) (2.4)
where i is the index of the transactions admitted into the system. Thepseudo code for FC-U is as follows:
FC-U(Us, KPU) {dU (k) = KPU × (US − u(k));teu(k + 1) = teu(k) + dU (k); }
where KPU is the control parameter for the utilization controller. Sinceu(k) is naturally bounded in the range [0, 100%] FC-U cannot detect howseverely the system is overloaded when u(k) remains at 100%.
2.8. Feedback Control Algorithms
2.8.2 FC-M
FC-M is a similar algorithm to FC-U presented above, but it controls missratio [20]. The control loop samples deadline miss ratio periodically, com-putes a change in the total estimated utilization, denoted dM (k), and addsit to teu(k). New transactions are admitted if they comply with equa-tion (2.4). The pseudo code is as follows:
FC-M(MS, KPM) {dM (k) = KPM × (MS −m(k));teu(k + 1) = teu(k) + dM (k); }
where KPM is the control parameter for the deadline miss ratio controller.This algorithm calculates the change in total estimated utilization withoutknowledge of the utilization bound, but instead by the difference betweendeadline miss ratio in the last sampling window and the miss ratio refer-ence level. Since m(k) is naturally bounded in the range [0, 100%], FC-Mcannot detect how severely the system is underutilized when m(k) remainsat 0%.
2.8.3 FC-UM
FC-UM is an algorithm for integrated utilization and miss ratio control [20].The algorithm solves the problems of handling overloaded and underutil-ized systems that can occur in both FC-U and FC-M. Both miss ratio andutilization are monitored, fed back to their controllers and the control sig-nals are calculated separately. The control input of the utilization control,dU (k), and miss ratio control, dM (k) are compared and the smaller one issent to QoS actuator. New transactions are admitted if they comply withequation (2.4). The pseudo code is as follows:
FC-UM(MS, US, KPM, KPU) {dM (k) = KPM × (MS −m(k));dU (k) = KPU × (US − u(k));teu(k + 1) = teu(k) +min(dM (k), dU (k)); }
21
2.8.4 QMF
The QMF (a QoS-sensitive approach for Miss ratio and Freshness guaran-tees) [29] algorithm deals with issues handling updates of base data objectsto reflect the real-world environment, i.e., update transactions, while stillproviding resources for user transactions. QMF switches updating basedata from immediate to on-demand policy, providing more resources touser transactions, while still ensuring that read base data is fresh, i.e, inits absolute validity interval (see section 2.2.1). Prior studies implement-ing this algorithm on the COMET platform [5], has shown it to require tomuch resources to be of any value for system performance. By enhancingperformance of the COMET platform, the QMF algorithm could providehigher utilization for user transactions.
2.9 Adaptive Control Theory
The word“adapt”means changing to fit new circumstances. Adaptive feed-back control can be thought of as a special type of nonlinear feedback con-trol in which the states of the process can be separated into two categories,which change at different rates [4]. The slowly changing states are calledcontroller tuning variables. This separation introduces the idea of two timescales: a fast time scale for updating the ordinary feedback, and a slowerone for updating the controller tuning variables. While a regular feedbackcontroller is tuned for one particular environment setting, the adaptivecontroller tunes the feedback controller to adapt to a time-varying environ-ment, thus, automatically adjusting itself to better performance. Below wepresent two adaptive feedback control technologies, the self-tuning regulator(STR) and least squares and regression models.
2.9.1 Self-Tuning Regulator Control
When estimating the total utilization teu(k), it may differ from the totalactual utilization u(k), which can be written as [35],
u(k) = Ga(k)teu(k) (2.5)
2.9. Adaptive Control Theory
where Ga is called execution time factor . When the total actual utiliza-tion is below the utilization threshold uth(k), miss ratio m(k) = 0, sinceno transactions miss their deadlines. The utilization threshold is chosenaccording to
uth(k) ={
1, EDF scheduleru(k), 0 < m(k) < 0.005, other scheduler. (2.6)
The miss ratio linearized at the utilization threshold gives [35],
m(k) ={
0 (u(k) ≤ uth(k))m(k − 1) +GM (u(k)− u(k − 1)) (u(k) > uth(k)) (2.7)
where GM is the slope of linearization. Using (2.5) and (2.7), the corres-ponding closed-loop transfer function is [35],
Gc(z) =KPMGa(k)GM
z − (1−KPMGa(k)GM )(m(k) ≥ 0). (2.8)
Since Ga(k) may change from sample instant to sample instant, a newKPM (k) must be calculated to keep the pole location of the closed-looptransfer function constant. To obtain a stable system, the pole must belocated within the unit circle [35]. The new KPM (k) can be calculatedwith,
KPM (k) =1− p0
Ga(k)GM(2.9)
where p0 is the pole location. In this thesis p0 = 0.25 is chosen. By using(2.5) and estimating u(k) with m(k)
GM+uth(k) (see figure 2.5), a new Ga can
be estimated with [35],
Ga(k + 1) = (1− α)Ga(k) + α
m(k)GM
+ uth(k)teu(k)
(2.10)
where 0 < α < 2. A larger value of α provides better tracking ability, butis also more sensitive to rapid changes in miss ratio between samples [35].These two aspects should be considered when α is chosen. In this thesisα = 0.8 is chosen.
23
thu m(k)GM
GM
m(k)
u(k)
m
u(k)
Figure 2.5: Estimation of u(k)
2.9.2 Least Squares And Regression Models
Regression model algorithms are a family of algorithms with a black box ap-proach where little assumptions of the system are made [4]. Karl FriedrichGauss formulated the principle for least squares, stating that the unknownparameters in a mathematical model should be chosen in such a way that [4]:
The sum of the squares of the difference between the actuallyobserved and the computed values, multiplied by numbers thatmeasure the degree of precision, is a minimum.
2.9. Adaptive Control Theory
The least-squares model is particularly simple for a mathematical model,called a regression model , written in the form,
y(k) = ϕ1(k)θ1(k) + ϕ2(k)θ2(k) + . . .+ ϕn(k)θn(k) = ϕT (k)θ(k) (2.11)
where y is the observed controlled variable,
θ(k) =(θ1(k) θ2(k) . . . θn(k)
)Tare the parameters of the model to be calculated, and
ϕT (k) =(ϕ1(k) ϕ2(k) . . . ϕn(k)
)are known functions that may depend on other known variables and arecalled the regression variables or the regressors [4].
The model is indexed by the variable k, which denotes a sample taken ina sampling window ((k − 1)T, kT ), where T is the sampling period. Usingan estimation of the controlled variable, y(t), the parameter θ should bechosen to minimize the least-squares loss function [4],
V (θ, k) =12
k∑i=1
(y(i)− y(k))2. (2.12)
In adaptive controllers the observations are obtained sequentially in real-time. Using the recursive least-squares algorithm (RLS) below, the resultsobtained at the sampling instant k− 1 can be used to get the estimates atthe kth sample [19]. Let θ(k− 1) be an estimate of θ(k− 1). The estimateof y(k) given by,
y(k) = ϕT (k)θ(k − 1) (2.13)
and the prediction error ,
ε(k) = y(k)− y(k) (2.14)
are calculated. The RLS algorithm calculates a new estimate of θ at thekth sampling instant according to,
25
ε(k) = y(k)− ϕT (k)θ(k − 1)
P (k) =1λ
(P (k − 1)− P (k − 1)ϕ(k)ϕT (t)P (k − 1)
λ+ ϕT (k)P (k − 1)ϕ(k)
)K(k) = P (k)ϕ(k)
θ(k) = θ(k − 1) +K(k)ε(k). (2.15)
The P (k) matrix is defined as
P (k) =( k∑i=1
ϕ(k)ϕT (k))−1
. (2.16)
The RLS algorithm calculates P (k) according to 2.15, to be able performrecursive calculation. K(k) matrix is introduced as a temporary matrixfor simplifying computation. For each sampling instant, the algorithmcalculates the prediction error, ε(k), updates the P (k) and K(k) matrixes,and finally adds a factor K(k) · ε(k) to the θ(k − 1) estimations, in orderto generate a new parameter estimation, θ(k).
In RLS a forgetting factor, 0 < λ < 1, is used to decide the import-ance of old measurements when the algorithm minimizes the loss func-tion, V (θ, k), to find θ(k). A smaller value of λ provides better trackingability, but is also more sensitive to rapid changes in miss ratio betweensamples [37]. In this thesis λ = 0.5 is used.
After an estimate of the model parameters has been calculated, futurevalues of y can be predicted by calculating
y(k + 1) = ϕT (k + 1)θ(k). (2.17)
2.9. Adaptive Control Theory
27
Chapter 3
Problem Description
In this chapter a description of the problem is given. Section 3.1 describescurrent COMET deficiencies. In section 3.2 a proposal for dynamic re-configuration of COMET during run-time is outlined. Adaptive feedbackcontrol architecture, algorithms and metrics are explained in section 3.3.In section 3.4 our aim and objectives are specified.
3.1 COMET Improvements
This section specifies improvements done to the COMET baseline duringthis thesis project. The baseline represents the basic standard setup ofCOMET components. The section consists of the merging of COMETv2.0 and v1.5 into COMET v3.0, and of the correction of other COMETdeficiencies.
3.1.1 COMET Merging
Two different parallel COMET baselines exist, both originally built onthe initial COMET v1.0 [10], with different functionality, interfaces etc.COMET v1.5, developed in two former thesis projects [11, 5], supportsconcurrency control and QoS management. COMET v2.0, is an enhanced
3.1. COMET Improvements
version of COMET v1.0 that has been redesigned, bug-fixed, and optimized,for better performance and functionality. The first task when improvingCOMET should be to merge COMET v1.5 and COMET v2.0 into COMETv3.0, suitable for all future development by all COMET project members.
3.1.2 COMET Deficiencies
When the COMET platform was extended with concurrency control andQoS [11, 5], a number of design and implementation deficiencies were de-tected. To achieve successful further development of COMET, implement-ation of component swapping, and successful implementation of adaptivealgorithms, these deficiencies, stated in the bullet list below must be ad-dressed, either by being implicitly fixed when merging the COMET v1.5and COMET v2.0 version, or afterwards:
• The implementation does not have distinct interfaces, operations andmechanisms, thus not conforming to ACCORD and RTCOM. Re-structuring of the code into more distinct interfaces, operations andmechanisms should be done.
• Mechanisms in some components call operations in other components.This should be corrected so components only can communicate withother components via operations.
• Memory leaks exist and uninitialized memory is read at certain points,e.g., when performing index searches in the IMC and when writingmeta-data to the memory. All memory leaks in COMET should befound and fixed to ensure a more stable system.
• Tuples are not updated correctly on attribute updates, and delet-ing tuples corrupts the meta-data. Correction of this basic databasefunctionality should be done.
• When a relation is loaded, an index search is performed for eachkey in the relation. Since relations are loaded upon every databaseoperation, this behavior causes performance to degrade heavily. Amore efficient way of handling indexing should be implemented.
29
• Problems exist when passing data in aspects. When passing data,arguments should be replaced by data structures.
• Operations are too coarse granule with large amounts of code. Theoperations should be divided into more fine granule logical pieces ofcode, i.e., mechanisms.
• Transactions in COMET have very long execution times. Profiling ofCOMET to identify time-consuming functional parts and optimiza-tion of code should be done to lower execution times.
• Naming and coding standards do not exist, and therefore need tobe outlined in order to enhance code readability and future work onCOMET.
• Error handling in COMET is inferior and a more extensive and effi-cient way of handling errors should be developed.
• Other performance issues, e.g, a number of inefficient sequential search-es which search through complete arrays even though they could beempty or contain only a few elements, exist and should be optimized.
3.2 Dynamic Reconfiguration
Since COMET is composed of different components, one benefit is thepossibility to swap one component for another. This can indeed be doneat compile time, but a monolithic system is then created. In embeddedsystems with requirements on high up-time it may not be possible to tem-porarily shut down the system for reconfiguration, but instead be able todynamically reconfigure the system during run-time. This in turn setsdemands on the feedback control of the system to adjust to these newconditions, since a new system has been created (see section 3.3).
The components in COMET are differently difficult to make swappableduring run-time, due to complexity of interfaces and the need to storeand transfer their internal state to the new version of the component, andtherefore all COMET components may not be suitable for swapping. Theissue of whether a component should be allowed to be swapped or not can
3.3. Adaptive Feedback Control
be addressed by outlining a set of rules for what need to be fulfilled, i.e., aconformance rule set .
Another problem that exists when swapping COMET components, isthe fact that the concurrency control and QoS management aspects crosscutseveral of the components. When swapping a component, the consistencyof aspect internal states and functionality must be guaranteed.
3.3 Adaptive Feedback Control
Feedback control provides COMET with functionality for enforcing QoSin a real-time system during workload variations and other time invari-ances [5]. However the controllers behavior are not updated according toworkload variations and changes to the database configuration, but insteadtuned based on the fixed database configuration and an estimated work-load. Delays in execution time due to, e.g, CPU resource scheduling, andthe introduction of component swapping into COMET, makes it difficultfor traditional feedback control to achieve satisfactory or optimal results.By using adaptive control it is possible to achieve better QoS managementby constantly monitoring the system and updating the controllers accord-ing to workload and execution time variations, and also when the databaseconfiguration is changed.
3.3.1 Adaptive Feedback Control Algorithms
Two different adaptive feedback control algorithms are compared in thisthesis with regard to the metrics identified in section 2.7.2. Both algorithmsmonitor miss ratio, i.e, use the FC-M algorithm. Since FC-M is a propor-tional controller, adjustments of it are made to fit the adaptive algorithmsspecified below. Both algorithms use the same basic architecture, but dif-ferences exist in the way the controller tuning variables are calculated:
• AFC-M-STR (Adaptive Feedback Control-Miss ratio-Self-Tuning Reg-ulator), uses a self tuning regulator described in section 7.2.1.
• AFC-M-RM (Adaptive Feedback Control-Miss ratio-Regression Mo-del), uses the regression model algorithm described in section 7.2.2.
31
3.3.2 Metrics
The different algorithms described in section 2.9 differ in regard to usageof resources. Two metrics relevant for choosing these algorithms are:
• CPU usage
• Memory usage
Since many embedded real-time systems have scarce CPU and memoryresources, these metrics are of great importance.
3.4 Aim and Objectives
The aim of this project is to stabilize the COMET platform and render thepossibility to swap components during run-time. COMET extensions forproviding adaptive QoS management should also be implemented. Achiev-ing this aim includes the following activities:
1. Study the theory behind adaptive control theory, component swap-ping and the COMET system.
2. COMET Improvements
• Merge the COMET v1.5 and COMET v2.0 baseline versions intoCOMET v3.0.• Improve COMET platform by addressing deficiencies stated in
section 3.1.• Rigid testing of the improved version of the COMET platform.
3. Dynamic Reconfiguration
• Determine if dynamic reconfiguration can be performed on(a) components(b) components with woven aspects
• Outline a conformance rule set for what needs to be fulfilled fordynamic reconfiguration to be allowed.• Implement dynamic reconfiguration during run-time
3.4. Aim and Objectives
4. Adaptive Control
• Choose adaptive feedback control algorithms according to met-rics.
• Implement the AFC-M-RM and AFC-M-STR adaptive algorithmsin COMET using components and aspects.
• Develop a test bench for performance evaluation of the adaptivealgorithms.
• Performance evaluation of the AFC-M-RM and AFC-M-STRalgorithms.
• Performance evaluation of Adaptive QoS COMET in comparisonto regular QoS COMET.
• Performance evaluation of Adaptive QoS COMET under theimpact of the dynamic reconfuration.
33
Chapter 4
Advanced Preliminaries
This chapter describes the COMET components (section 4.1) and the exe-cution flow of a transaction in COMET (section 4.2). Section 4.3 describesthe different aspect packages available, and briefly how they work.
4.1 COMET Components
COMET consists of the components described in this section. Figure 4.1illustrates how the components relate to each other. An arrow from onecomponent to another means that the first component uses the secondcomponent. Since the BMC is a subcomponent of the TMC, it is drawnwith a dashed line. The UIC uses the SMC in case of concurrency, which iswhy the arrows connecting those components are dashed. In case of runningCOMET non-concurrently, the TMC is used directly by the UIC. The LMCis not used in the non-concurrent configuration of COMET, which is thereason why no arrows are connected to it. Aspects should weave in codeto use the LMC when dealing with locks.
4.1. COMET Components
UIC
SMC
LMC
IMC MMC
TMC BMC
Figure 4.1: COMET components and their relations
4.1.1 User Interface Component (UIC)
The UIC is the connection point for applications when using the COMETdatabase. The applications use the UIC interfaces to create and executenew transactions. The UIC stores every transaction present in the systemin an array of DBTrans structs, which contains transaction specific informa-tion. After a transaction is initialized, with a call to RUIC_Op_beginTrans-action, strings containing queries can then be sent to the transaction. Thequeries, consisting of a SQL-like syntax [10], are parsed by the UIC, andcorresponding execution trees are built and stored in the corresponding
35
DBTrans struct. When all queries belonging to a transaction have beensubmitted, the application sends a commit command to the UIC and thetransaction starts to execute. Last the UIC provides the result of the trans-action to the application.
4.1.2 Scheduler Manager Component (SMC)
The SMC manages a set of threads, called a thread pool . Every transactionmust be assigned a thread to execute within by the SMC. The number ofthreads available in the pool is set with a system parameter, and can bealtered by a database user to meet certain requirements. A ready queue andactive queue are also maintained by the SMC. Transactions that currentlyexecute are stored in the active queue, and transactions waiting for storedare kept in the ready queue.
When a transaction τ is committed, the UIC sends a submit requestto the SMC, which puts the transaction in the ready queue and then triesto execute the transaction with a scheduling request. Three scenarios arethen possible.
1. The thread pool contains at least one thread, which can immediatelybe assigned to τ . τ is removed from the ready queue and put in theactive queue and starts to execute.
2. The thread pool is empty, and the transactions currently executinghave at least the same priority as τ . τ then has to wait in the readyqueue to be scheduled by the SMC. The next transaction to executeis chosen with a scheduling algorithm, e.g., EDF.
3. The thread pool is empty, and at least one of the currently executingtransactions has lower priority than τ . The transaction with lowerpriority is rolled back before completion to return its thread to thethread pool. τ is assigned the available thread and starts to execute.
The threads from the thread pool are themselves scheduled by the operatingsystem. When a transaction is completed it is removed from the activequeue and its thread is returned to the thread pool. If a transaction isrolled back before completion, the transaction is removed from the active
4.1. COMET Components
queue and then put back in the ready queue and its thread is reassignedby the scheduler.
4.1.3 Transaction Manager Component (TMC)
The TMC executes a transaction by traversing the execution trees belong-ing to the transaction sequentially, using the recursive RTMC_Mech_Resultfunction, which is the core function of the TMC. For each execution treethe affected relations are loaded into buffers, using the IMC and the MMC.The tuples not needed in the query are deleted. The operations of thequery are performed on the tuples in the buffers. If a transaction containsan update query, all the affected tuples must be written back in memory,using the IMC and MMC. When finished with a parse tree, the TMC startswith the parse tree. When finalizing the last tree, the TMC informs theSMC that the transaction is completed. The Buffer Manager Component(BMC), which handles the buffers, is a subcomponent of the TMC.
4.1.4 Locking Manager Component (LMC)
The LMC manages a list of locks, and provide functionality for manipula-tion of locks, which can be used by, e.g., concurrency aspects.
4.1.5 Indexing Manager Component (IMC)
The IMC is used to find tuples in relations by storing their addresses insearchable trees. These addresses are used when reading or writing tupleswith the MMC. The IMC provides functionality for managing relationsand tuples, e.g., insertion of new tuples. Two separate IMC componentsexist, one default used for all COMET configurations except GUARD-Link,which uses a B-Link IMC version.
4.1.6 Memory Management Component (MMC)
The MMC provides memory operations, used by the TMC to manage rela-tions, and by the IMC to manage the index. The MMC operations are forallocating, deallocating, reading, and writing to memory. An additional set
37
of identical operations exist, intended to be used when weaving in aspectadvice.
4.2 Transaction Flow
Transactions in COMET perform a certain set of steps when executing,which are shown in figure 4.2. For each step in the figure, every componentinvolved in this step is presented. The steps are as follows.
1. A user sends an SQL query, as a string, to the UIC. The UIC theninitiates a new transaction for the user query.
2. The query string is parsed, and a corresponding execution tree isproduced.
3. If concurrency control is applied, the transaction waits to be sched-uled by the SMC, and then assigned to an available thread to startexecuting in. How conflicts are detected and resolved depends onwhich concurrency aspect used, and can be studied more in depthin [11]. Without concurrency control this step is omitted and theTMC is called directly from the UIC.
4. The TMC loads the relations needed by the query into buffers. Eachrelation is loaded in the following manner. First, the IMC is usedto get the address of the metadata for the relation. The MMC isthen used to read the metadata from memory. The TMC stores themetadata in a buffer. The metadata is used to describe the propertiesof the relation and its attributes, such as the name and types of theattributes. Thereafter the TMC locates every tuple in the relation byusing the IMC, and reads the tuples into the buffer, using the MMC.
5. The tuples not needed by the query are deleted from the buffer.
6. The operations of the queries are performed on the tuples in thebuffer, e.g., to change the value of an attribute. If the transaction isof read-only type, the transaction leaves the TMC at this point, andthe dashed route to step 8 is followed.
4.2. Transaction Flow
7. If the transaction contains an update query, the tuples affected in theprevious step are written back to memory by first using the IMC toreceive the correct address of the tuple, and then by using the MMCto write the tuple data to memory.
8. The result is presented to the user using the UIC, which uses theTMC.
9. Finally, if a concurrent configuration is used, the transaction threadis released and given back to the SMC thread pool.
BMC
UIC TMC BMC
queryEnter Parse
querySchedule
transactionLoadrelation
Removetuples
Performoperations
Updatetuples
TMCTMCTMC
UIC SMC BMC
BMCBMC
IMC
IMC
MMC
MMC
TMC
2 4
567
1 3
Presentresult
Returnthread
SMC
8 9
UIC
Figure 4.2: The execution steps of a transaction in COMET
The execution steps when performing transactions with deletion or inser-tion of tuples are similar. Differences worth mentioning are that metadatais updated as well in step 7 and that step 5 is omitted on inserts.
39
4.3 Aspect Packages
COMET consists of several different configurations, both for concurrencycontrol (section 4.3.1) and QoS management (section 4.3.2). An aspectpackage is a set of aspects, which combined with the COMET compon-ents constitute a COMET configuration. All concurrency control packagescan be used with any of the QoS packages. Instructions on how to buildthe different COMET configurations can be found in the COMET UserManual [21]. Since join points have been changed since the original im-plementation of the concurrency control and QoS management aspects,documentation of the updated aspects can be generated by running a buildscript also documented in the COMET User Manual [21].
4.3.1 Concurrency Aspects
Three different concurrency control configurations, described briefly below,can be used with COMET. For a more in detail description of the concur-rency algorithms see [11].
HP2PL With Similarity
High-Priority 2-Phase Locking (HP2PL) [1] is a locking scheme based onregular 2-Phase Locking (2PL). HP2PL takes priorities into account, 2PLdoes not. Different locks are acquired on read and write operations ondata items. Variants of HP-2PL exist, using different conflict resolutionmethods. HP-2PL suffers from unbounded number of transaction restartsand unbounded waiting times. Thus, it is not suitable for hard RTSs, butfor soft ones.
ODC
Optimistic Divergence Control (ODC) [36] is based on an concurrency con-trol method which uses weak and strong locks. As a transaction executesit asynchronously acquires weak read and write locks on the accessed dataitems, and updates data in local space. If a strong lock is held on any of theitems, the requesting transaction is marked for abortion. The transactionsthat are marked for abortion are aborted when they enter the validation
4.3. Aspect Packages
phase. Aborted transactions wait a certain amount of time before restart-ing. If a transaction has not been marked for abortion during its execution,it is allowed to commit when it enters the validation phase. During commit,all of the weak write locks a transaction holds are temporarily converted tostrong locks. Any transaction that holds a weak lock on a data item thatgets locked by a strong lock in this phase, is marked for abortion.
GUARD-Link
GUARD-Link [14] uses the Gate-keeping Using Adaptive eaRliest Deadline(GUARD) admission control combined with a concurrent B-link index al-gorithm. The GUARD admission control decides which transactions thatare allowed to execute at all, based on feedback control and a randomfactor. Index operations in the B-link tree lock tree nodes and subtrees,typically locked on descent, and the locks are kept if modification of thetree is needed, otherwise they are released.
4.3.2 QoS Aspects
Two different QoS management configurations can be used with COMET.The configurations use a number of aspects to implement their functional-ity.
ACC
The Admission Control Configuration (ACC) requires the use of:
• The Quality of service Actuator Component (QAC) intercepts re-quests to create new transactions from the UIC to the SMC. Basedon an admission policy, the actuator decides whether to allow therequests to reach the SMC, or to reject the transactions.
• The Transactional Real-Time Aspect (TRTA) adds an estimated util-ization to the COMET transaction model. TRTA also transfers theutilization and deadline set in the application for all transactions tothe SMC.
41
• The Quality of service Actuator Composition Aspect (QACA) facilit-ates the insertion of the QAC between the UIC and the SMC.
When using ACC the QACA inserts the QAC between the UIC and SMCby allowing QAC to intercept all requests to create new transactions. Byusing the estimated utilization, introduced by the TRTA and equation 2.4,a new transaction is either admitted or rejected.
MRFC
The Miss Ratio Feedback Configuration (MRFC) requires the use of allACC components and aspects, and additionally:
• The Feedback Controller Component (FCC) computes input to theadmission policy of the QAC at regular intervals. By default, aninput of zero is generated, but aspects can be woven into FCC toaccommodate various QoS algorithms. FCC is run on its own threadof execution.
• The Feedback Controller Composition Aspect (FCCA) initializes theFCC.
• The Missed Deadline Monitor Aspect (MDMA) modifies the SMC tokeep track of the deadline miss ratio, using equation 2.3.
• The Utilization from Missed deadline Control Aspect (UMCA) mod-ifies the FCC to base its calculation of input to the admission policyof the QAC, on the deadline miss ratio of the system.
The MRFC uses the same admission control as the ACC. Apart from thatMRFC implements the FC-M algorithm (section 2.8.2). The FCCA initial-izes the FCC, which regularly computes input to the admission policy of theQAC, based on the deadline miss ratio of the system, which is monitoredby MDMA and calculated by UMCA.
4.3. Aspect Packages
43
Chapter 5
COMET Improvements
This chapter contains a specification of COMET v3.0, merged from COMETv1.5 and COMET v2.0. The chapter also provides the improvements im-plemented in COMET v3.0. Furthermore the chapter contains a section ontesting of COMET v3.0, a description of the COMET API and debug tool,and a section specifying a COMET coding and naming standard. The lastsections of the chapter provides changes made to COMET v3.0, directlymapped to the thesis problem description (chapter 3).
5.1 Prerequisites
Two parallel COMET baselines exist, both originally built on the initialCOMET v1.0 [10], having different functionality, interfaces etc. COMETv1.5, developed in two former thesis projects ([11] and [5]), supports con-currency control and QoS management. COMET v2.0, developed at Malar-dalens Hogskola, is an enhanced version of v1.0, as it has been redesigned,bug-fixed, and optimized, for better performance and functionality. Themajor changes done in COMET v2.0 can be found in table 5.1.
5.1. Prerequisites
Comp. Change doneALL Dereferenced the Btable ** buffer throughout the project.
General minor bugfixing.UIC New function created, getParseTree, used for creation of execution
parse trees.Added struct DBTrans, containing all transaction specific informa-tion, to accommodate a new transaction model.Changed the behavior/interface of functions to use the DBTransstruct:
• RUIC commitTransaction
• RUIC rollbackTransaction
• RUIC beginTransaction
• RUIC Query
Created a destructor, RUIC freeTransaction, for the DBTrans struct.Created a function, RUIC printTransaction, to print the result of atransaction.Removed functions no longer in use, since all transaction specific in-formation is now in the DBTrans struct:
• PutHandleinTree
• PutInHandleTree
• SearchHandle
• makeHandleTree
• findHandleTree
Changed newNode function to use Dmalloc, by that found somememory leakage.Bug-fixed a memory leak in UIC moreAttrs.
TMC Cleaned the Result function with regard to unused variables etc.Broke out Update, Create and Drop into separate functions.Removed all old references to handle trees, transaction lists etc., whichare no longer in use.Removed all traces of database pointers in the Result function. Thisfunctionality is now contained in DBPTMC instead.Removed attributes in the Result function, also affecting all calls toit.
Table 5.1: COMET v2.0 Changes
45
5.2 Approach
The first step in improving COMET according to section 3.1.2 should be tomerge the two COMET versions, v1.5 and v2.0, into a new version calledCOMET v3.0. The benefits of doing this are:
• Creating common baseline to be used for all future development byall COMET project members.
• Providing possibility for all COMET project resources at MalardalensHogskola and Linkopings University to push the overall COMET pro-ject status forward in a mutually beneficial way.
• Setting standards and guidelines for future development of COMET.
• Incorporating improvements already made in the COMET v2.0 ver-sion, to solve problems stated in section 3.1.2.
Two different options exist when merging the COMET v1.5 and COMETv2.0 versions. The first option is to start with the COMET v1.5 versionand reimplement or copy, some or all of, the changes done in COMETv2.0. The other option is to start with COMET v2.0, and add the changesmade in the COMET v1.5 version to provide scheduling, locking, threadhandling, concurrency control and QoS management functionality.
The benefits of the first option would be that changes could be chosenin a way that concurrency control and QoS management aspects would notbe affected. Therefore less time would be needed to study and alter theseaspects. A major drawback of the first option, is that the merged versioncould not serve as a common base for all future development, since it wouldnot fulfill all COMET project members needs. This is the reason why thesecond option is chosen.
After merging the two versions into COMET v3.0, all other COMETimprovements not already solved implicitly by using COMET v2.0 as abase for merging versions, e.g., fixing errors on tuple updates and enforcinga naming and coding standard, are implemented.
5.3. Merging Into COMET v3.0
5.3 Merging Into COMET v3.0
When merging the prior versions of COMET into COMET v3.0, COMETv2.0 was used as starting point. All design and implementation changesmade to COMET v3.0 were made with the intention of making concurrencycontrol and QoS management aspects working correctly. The changes im-plemented in COMET were done to both components and aspects cross-cutting COMET. During development of COMET v3.0 several iterationsof changing component and aspect code were made. The changes made canbe summarized as follows:
• Component Changes, were mainly done to add support for concur-rent transactions in COMET. A detailed description of componentchanges implemented, as well as the motivation behind the changes,can be found in table 5.2 and 5.3.
• Aspect Changes, consisted mainly of changing join points and functioncalls to components within the aspect advice and functions, sincefunction names in COMET v3.0 have been changed since previousversions. A more detailed description of aspect changes implementedcan be found in table 5.4 and 5.5.
• Other changes, mainly concerned getting COMET v3.0 to run onUNIX. Since COMET v2.0 was written for Windows, changes hadto be made to the platform specific files for COMET to functionproperly on UNIX. Additionally, several bugs which where fixed inCOMET v1.5, but had been removed in COMET v2.0, where againimplemented in COMET v3.0.
5.4 Testing COMET v3.0
Testing of COMET v3.0, including its concurrency and QoS configurations,has been done in several ways. To verify COMET v3.0 without any aspectsa set of transactions where submitted to the system and the output wasanalyzed. A listing of the transaction run and the results can be found in
47
Com
p.
Ch
an
ge
don
eM
oti
vati
on
UIC
Ad
ded
5op
erati
on
sto
the
UIC
inte
rface
,w
hic
hare
use
dw
hen
run
nin
ga
con
curr
ent
con
figu
rati
on
of
CO
ME
T.
Exte
nd
the
CO
ME
TA
PI
for
con
curr
ency
.A
dd
edth
eUIC_SystemParameters
stru
ctfr
om
CO
ME
Tv1.5
,u
sed
wh
enw
eavin
gQ
oS
asp
ects
into
CO
ME
T.
Mad
ep
ara
met
ers
more
suit
-ab
lefo
rasp
ect
wea
vin
g.
Cre
ate
da
glo
bal
arr
ay
wit
hDBTrans
stru
cts
inth
eU
IC,
wh
ich
isu
sed
toh
old
all
curr
ent
tran
sact
ion
sth
at
have
arr
ived
toth
eC
OM
ET
syst
em.
To
store
info
rmati
on
ab
ou
tev
ery
tran
sact
ion
pre
sent
inth
eC
OM
ET
syst
em.
Rem
oved
theRUIC_freeTransaction
fun
ctio
n,
sin
ced
eall
oca
tion
of
theDBTrans
stru
cts
are
no
lon
ger
nee
ded
.S
imp
lifi
edtr
an
sact
ion
mod
elan
dh
an
dli
ng
of
tran
sact
ion
s.M
erged
theUIC_InputTransaction
stru
ct,
from
CO
ME
Tv1.5
,in
toth
eDBTrans
stru
ct.
Use
dfo
rad
din
gatt
rib
ute
sto
atr
an
sact
ion
wh
enru
nn
ing
con-
curr
ency
contr
ol.
Ad
ded
dea
dli
ne
as
an
att
rib
ute
toth
eDBTrans
stru
ct.
Use
dto
ab
ort
tran
sact
ion
sand
by
sch
edu
lin
galg
ori
thm
sw
hen
run
nin
gco
ncu
rren
tly.
Ch
an
ged
the
way
con
curr
ent
tran
sact
ion
sru
nin
the
UIC
,th
us
sim
-p
lify
ing
its
fun
ctio
nali
ty.
Sev
eral
fun
ctio
ns
that
exis
ted
inC
OM
ET
v1.5
are
no
lon
ger
nee
ded
.T
he
fun
ctio
nRUIC_Op_startTransaction
now
call
sSMC_Op_submitTransaction.
To
let
the
SM
Ch
an
dle
more
of
con
curr
ency
fun
ctio
nali
ty.
Th
efu
nct
ionRUIC_Op_lookupTransaction
was
ad
ded
.T
ob
eab
leto
look
upDBTrans
ob
ject
s,by
tran
sact
ion
iden
ti-
fier
,in
theTransList.
Th
efu
nct
ion
sRUIC_Op_startTransactionByThread
an
dRUIC_Op_restartTransactionByThread,
use
din
crea
tion
of
thre
ad
s,are
moved
toth
eS
MC
.
To
let
the
SM
Ch
an
dle
more
of
con
curr
ency
fun
ctio
nali
ty.
TM
CIn
tegra
ted
BM
C,
taken
from
CO
ME
Tv2.0
,as
asu
bco
mp
on
ent
toT
MC
,an
dad
ded
two
BM
Cop
erati
on
sto
the
TM
Cin
terf
ace
.T
he
BM
Cw
as
alm
ost
on
lyu
sed
by
the
TM
C.
Som
eM
MC
fun
ctio
nca
lls
wer
eex
chan
ged
toco
rres
pon
din
gfu
nc-
tion
su
sed
for
asp
ect
wea
vin
g,
e.g.,
MMC_Op_writeData
isex
chan
ged
forMMC_Op_writeTuple.
To
wea
ve
asp
ects
on
lyin
toso
me
of
the
MM
Cfu
nct
ion
call
s..
Ad
ded
UN
IXsp
ecifi
cm
acr
os
toth
em
etad
ata
hea
der
file
.B
ecau
seso
me
fun
ctio
ns
are
not
sup
port
edby
UN
IX,e.
g.,itoa.
Tab
le5.
2:C
ompo
nent
chan
ges
duri
ngC
OM
ET
impr
ovem
ents
5.4. Testing COMET v3.0
Com
p.
Ch
an
ge
don
eM
otiv
atio
nS
MC
Th
eS
MC
was
initia
llyta
ken
com
pletely
from
CO
ME
Tv1.5
.It
was
on
lyu
sedin
v1.5
.T
heSMC_ScheduleRecord
struct
has
been
removed
,sin
ceit
was
used
on
lyto
store
au
niq
ue
tran
sactio
nid
entifi
eran
da
dea
dlin
e,w
hich
isn
ow
inclu
ded
inth
eDBTrans
struct.
To
simp
lifysch
edu
lerd
ata
structu
res.
Fu
nctio
nd
eclara
tion
sh
ave
been
chan
ged
tota
ke
either
au
niq
ue
tran
s-actio
nid
entifi
eror
aDBTrans
struct
as
para
meter.
Th
ered
und
ant
data
typ
eSMC_ScheduleRecord
has
been
removed
.T
he
fun
ctionSMC_Op_submitTransaction
was
ad
ded
.T
oco
nfo
rmto
AC
CO
RD
.T
he
fun
ction
sSMC_Mech_restartTransactionByThread
and
SMC_Mech_startTransactionByThread
was
moved
here
from
the
UIC
.
To
letth
eS
MC
han
dle
more
of
con
curren
cyfu
nctio
nality,
an
dto
sup
port
the
CC
F.
Imp
ort
an
dex
port
fun
ction
ality
fun
ction
sw
eread
ded
.T
osu
pp
ort
CC
F.
Th
efu
nctio
nSMC_Mech_getNextToExecute
was
mod
ified
toalso
be
ab
leto
return
tran
sactio
ns
with
atra
nsa
ction
iden
tifier
of
zero.
Sin
cetra
nsa
ctions
with
an
tran
sactio
nid
entifi
erof
zeron
ow
isallo
wed
.IM
CA
dd
ed5
fun
ction
sfro
mC
OM
ET
v1.5
,w
hich
just
call
an
oth
erco
rres-p
on
din
gfu
nctio
nth
at
perfo
rms
the
actu
al
task
.T
hese
fun
ctions
are
used
inp
laces
wh
ereco
de
shou
ldb
ew
oven
inby
an
asp
ect.If
no
code
isto
be
woven
in,
the
orig
inal
fun
ction
isca
lled.
To
simp
lifyasp
ectw
eavin
gan
dm
ake
the
com
pon
ent
more
asp
ect-friend
ly.
Re-a
dd
edvoid
poin
terty
pe
conversio
ns
from
CO
ME
Tv1.5
,th
at
had
been
removed
inC
OM
ET
v2.0
.T
oavoid
com
pila
tion
errors
wh
enu
sing
gcc/
g+
+.
MM
CA
dd
ed4
fun
ction
sfro
mC
OM
ET
v1.5
,w
hich
just
call
an
oth
erco
rres-p
on
din
gfu
nctio
nth
at
perfo
rms
the
actu
al
task
.T
hese
fun
ctions
are
used
inp
laces
wh
ereco
de
shou
ldb
ew
oven
inby
an
asp
ect.If
no
code
isto
be
woven
in,
the
orig
inal
fun
ction
isca
lled.
To
simp
lifyasp
ectw
eavin
gan
dm
ake
the
com
pon
ent
more
asp
ect-friend
ly.
LM
CT
he
LM
Cw
as
taken
com
pletely
from
CO
ME
Tv1.5
.It
was
on
lyu
sedin
v1.5
.Q
AC
Th
eQ
AC
was
taken
com
pletely
from
CO
ME
Tv1.5
.It
was
on
lyu
sedin
v1.5
.C
han
ged
para
meters
tofu
nctio
ns
toDBTrans
structs,
since
the
SMC_ScheduleRecord
struct
isrem
oved
.T
he
SMC_ScheduleRecord
struct
ism
erged
into
the
DBTrans
struct.
FC
CT
he
FC
Cw
as
taken
com
pletely
from
CO
ME
Tv1.5
.It
was
on
lyu
sedin
v1.5
.
Table
5.3:C
ont.C
omponent
changesduring
CO
ME
Tim
provements
49
Asp
ect
Ch
an
ge
don
eM
oti
vati
on
HP
2P
LW
ith
Sim
ilar-
ity
Ch
an
ged
dou
ble
poin
ters
tosi
ngle
poin
ters
inall
join
poin
ts,
an
dre
spec
tivel
yd
ou
ble
poin
ters
tosi
ngle
poin
ters
inall
asp
ect
fun
ctio
np
ara
met
ers,
wh
ere
the
arg
um
ent
was
ad
ou
ble
poin
ter
toaBtable
bu
ffer
stru
ct.
To
matc
hth
easp
ect
toco
mp
on
ent
chan
ges
mad
e.
Cre
ate
dse
para
ted
ata
typ
esfi
les
To
sup
port
CC
F.
OD
CC
han
ged
dou
ble
poin
ters
tosi
ngle
poin
ters
inall
join
poin
ts,
an
dre
spec
tivel
yd
ou
ble
poin
ters
tosi
ngle
poin
ters
inall
asp
ect
fun
ctio
np
ara
met
ers,
wh
ere
the
arg
um
ent
was
ad
ou
ble
poin
ter
toaBtable
bu
ffer
stru
ct.
To
matc
hth
easp
ect
toco
mp
on
ent
chan
ges
mad
e.
Ch
an
ged
thetransactionInputted
poin
tcu
tta
ke
aDBTrans
stru
ctas
an
arg
um
ent
,in
stea
dof
aUIC_InputTransaction
stru
ct.
Ch
an
ged
the
ad
vic
eto
get
tran
sact
ion
info
rmati
on
from
theDBTrans.
Sin
ceth
eUIC_InputTransaction
stru
cth
as
bee
nm
erged
into
the
DBTrans
stru
ct.
Ch
an
ged
intr
od
uct
ion
of
theimportLimit
an
dexportLimit
vari
ab
les
from
theUIC_InputTransaction
stru
ct,w
hic
his
now
rem
oved
,to
theDBTrans
stru
ct.
Sin
ceth
eUIC_InputTransaction
stru
cth
as
bee
nm
erged
into
the
DBTrans
stru
ct.
Ch
an
ged
all
para
met
ers
inca
lls
toth
eS
MC
toei
ther
au
niq
ue
tran
sact
ion
iden
tifi
eror
aDBTrans
stru
ct,
sin
ceth
eSMC_ScheduleRecord
no
lon
ger
exis
ts.
Sin
ceth
eSMC_ScheduleRecord
stru
ctis
mer
ged
into
theDBTrans
stru
ct.
GU
AR
D-
Lin
kC
han
ged
all
para
met
ers
inca
lls
toth
eS
MC
toei
ther
au
niq
ue
tran
sact
ion
iden
tifi
eror
aDBTrans
stru
ct,
sin
ceth
eSMC_ScheduleRecord
no
lon
ger
exis
ts.
Sin
ceth
eSMC_ScheduleRecord
stru
ctis
mer
ged
into
theDBTrans
stru
ct.
MD
MA
Ch
an
ged
all
para
met
ers
injo
inp
oin
tsto
SM
Cop
erati
on
sto
aDBTrans
stru
ct.
Sin
ceth
eSMC_ScheduleRecord
stru
cth
as
bee
nm
erged
into
the
DBTrans
stru
ct.
Ch
an
ged
calc
ula
tion
of
dea
dli
ne
mis
sra
tio
inea
chsa
mp
le.
Calc
ula
tion
was
per
form
edin
cor-
rect
ly,
thu
sm
akin
gall
feed
back
contr
ol
per
form
an
ceev
alu
ati
on
don
ep
revio
usl
yon
CO
ME
T[5
,34]
qu
es-
tion
ab
le.
Tab
le5.
4:A
spec
tch
ange
sdu
ring
CO
ME
Tim
prov
emen
ts
5.4. Testing COMET v3.0
Asp
ect
Ch
an
ge
don
eM
otiv
atio
nQ
AC
AC
han
ged
join
poin
tp
ara
meter
for
ad
missio
nco
ntro
lp
oin
tcut
toDBTrans
struct.
Sin
ceth
eSMC_ScheduleRecord
struct
ism
erged
into
theDBTrans
struct.
Ch
an
ged
all
para
meters
inca
llsto
the
SM
Cto
aDBTrans
struct.
Sin
ceth
eSMC_ScheduleRecord
struct
ism
erged
into
theDBTrans
struct.
Ch
an
ged
calcu
latio
nof
tota
lestim
ated
utiliza
tion
,teu
(k),
toalso
inclu
de
tran
sactio
ns
inth
eS
MC
read
yqu
eue
with
tran
s-actio
nid
entifi
ereq
ual
tozero
.
Sin
cetra
nsa
ction
sw
ithan
transa
c-tio
nid
entifi
erof
zeron
ow
isallo
wed
.
TR
TA
Ad
ded
intro
du
ction
of
utilization
attrib
ute
toDBTrans
struct.
Sin
ceth
eSMC_ScheduleRecord
struct
has
been
merg
edin
toth
eDBTrans
struct.
Rem
oved
ad
vice
for
tran
sferring
utilization
from
SMC_ScheduleRecord
struct
toDBTrans
struct.
Sin
ceth
eSMC_ScheduleRecord
struct
has
been
merg
edin
toth
eDBTrans
struct.
Ad
ded
ad
vice
savin
gdeadline
an
dutilization,
setin
ap
-p
licatio
n,
befo
rere-p
oin
tingDBTrans
poin
terto
spot
intra
ns-
actio
nlist
inth
eU
IC.
The
ap
plica
tion
calls
RUIC_Op_beginTransaction
with
ad
ou
ble
poin
terto
aDBTrans
ob
jectco
nta
inin
gdeadline
an
dutiliz-
ation,
wh
ichsh
ou
ldb
esto
redin
theDBTrans
ob
jectrep
resentin
gth
etra
nsa
ction
inth
etra
nsa
ction
listin
the
UIC
.A
dd
edad
vice
for
restorin
gdeadline
an
dutilization
intra
nsa
ction
listto
valu
esit
had
befo
reth
eDBTrans
poin
terw
as
re-poin
ted.
To
store
deadline
an
dutilization
inth
eDBTrans
ob
jectrep
resentin
gth
etra
nsa
ction
inth
etra
nsa
ction
listin
the
UIC
.C
han
ged
ad
vice
tran
sferring
utilization
from
SMC_ScheduleRecord
struct
toSMC_Data
struct,
toin
stead
tran
sferth
eu
tilizatio
nfro
mth
eDBTrans
struct.
Sin
ceth
eSMC_ScheduleRecord
struct
has
been
merg
edin
toth
eDBTrans
struct.
FC
CA
—N
och
an
ges
need
edto
be
made.
UM
CA
—N
och
an
ges
need
edto
be
made.
Table
5.5:C
ont.A
spectchanges
duringC
OM
ET
improvem
ents
51
appendix D.1. The same set of transactions were also run with all com-binations of concurrency and QoS aspects, to verify that COMET wouldgenerate the same output regardless of configuration.
Testing Concurrency Control Aspects
Besides testing that transactions submitted to COMET generated the cor-rect result (appendix D.1), testing of the concurrency control aspects wasperformed in two different ways. Firstly, for all aspect advice, a code checkwas performed on the *.cc files generated by AspectC++, verifying thatall advice code was woven in correctly. Since HP2PL is used in later stages(chapter 8) of this thesis project, i.e., when running performance evaluationon the QoS algorithms, more in depth testing was performed using this con-currency algorithm. All tests run when initially implementing HP2PL [11],were verified also on COMET v3.0. The test runs included:
• Conflict Free Lock Request
• Conflict Resolution Based on Similarity
• Conflict Resolution Between Non-Similar Operations
• Meta-Data Conflict
• Abortion and Rollback
Testing QoS Management Aspects
Besides testing that transactions submitted to COMET generated the cor-rect result (appendix D.1), testing of the QoS management aspects wasperformed in two different ways. For all TRTA, QACA, FCCA, UMCAand MDMA advice, a code check was done in the *.cc files generated byAspectC++ [28], that all advice code was woven in correctly into the rightplaces in the code. Additionally a set of SELECT transactions where ex-ecuted and debug printouts were added to verify that transactions wereintercepted by the QAC. The QAC checks whether or not a transactionshould be admitted, and that the total estimated utilization, teu(k), isdecreased when transactions start missing their deadlines. A printout ofparts of such a run can be found in appendix D.2.
5.5. COMET API
5.5 COMET API
The Application Program Interface (API) is a specification for how applic-ations can be programmed to utilize the functions of a piece of software. Anumber of functions are available for applications using COMET. Depend-ing on if COMET is configured with or without concurrency control andQoS management, two different subsets of the API are used. The API isdescribed in the two following subsections.
5.5.1 COMET Without Concurrency and QoS
The following code is an example of COMET API which should be usedto execute a transaction in COMET without concurrency control and QoSmanagement.
1. DBTrans * trans;2. RTMC_Op_Init();3. RUIC_Op_beginTransaction(&trans);4. RUIC_Op_Query(trans,"SELECT * FROM emp;");5. RUIC_Op_commitTransaction(trans);6. RUIC_Op_printTransaction(trans);7. RUIC_Op_rollbackTransaction(trans);
To create a transaction a pointer to a DBTrans must be declared (line 1).The TMC must be initialized with a call to RTMC_Op_Init (line 2). RUIC-_Op_beginTransaction, BOT (Beginning Of Transaction), is called withthe address to the DBTrans pointer (line 3). A new DBTrans object rep-resenting the transaction is created internally in the UIC and the DB-Trans pointer is re-pointed to this object. After the transaction is cre-ated, the user can submit queries by calling RUIC_Op_Query, using thesame pointer used when calling RUIC_Op_beginTransaction and with astring containing the SQL query (line 4). RUIC_Op_commitTransaction,EOT (End Of Transaction), called with the DBTrans pointer is then usedto start executing the transaction queries (line 5). To view the result,RUIC_Op_printTransaction is called with the DBTrans pointer (line 6).Finally, RUIC_Op_rollbackTransaction is called with the DBTrans pointerto free up the transaction internally (line 7).
53
5.5.2 COMET With Concurrency and QoS
The following code is an example of COMET API that should be usedto execute a transaction in COMET with concurrency control and QoSmanagement.
1. DBTrans * trans;2. struct UIC_SystemParameters systemParameters;3. Time t, t2;4. _getTime(&t);5. _makeTime(&t2, 10000000);6. _addTime(&t, &t2, &t);
7. DBTrans inputTrans;8. inputTrans.deadline = t;9. trans = &inputTrans;
10. RUIC_Op_init(systemParameters);11. RUIC_Op_beginTransaction(&trans);12. RUIC_Op_Query(trans,"SELECT * FROM emp;");13. RUIC_Op_startTransaction(trans);14. RUIC_Op_cleanup()
To create mutexes and initialize components, COMET must first be calledwith RUIC_Op_Init (line 10), with a UIC_SystemParameters struct as anargument, which contains attributes introduced by aspects. A DBTrans anda UIC_SystemParameters object must be created (line 2 and 7). Dependingon which aspect packages are in use, different attributes should be set ineither the DBTrans and/or the UIC_SystemParameters struct. The reasonfor this is that different attributes are added by different aspects, e.g., theTRTA aspect adds utilization to the DBTrans struct. In this example anaspect which adds deadline to the DBTrans struct is used. A deadline t iscreated and assigned to the DBTrans object (lines 3-6 and 8). Aspects andcorresponding attributes woven into structs are presented in table 5.6.
RUIC_Op_beginTransaction (BOT) is called in line 10 with the addressof a pointer, pointing to the DBTrans object containing the attributes. Anew DBTrans object representing the transaction is created in the UIC, and
5.5. COMET API
Aspect package DBTrans UIC SystemParametersHP2PL deadline —ODC deadline —
importLimitexportLimit
Guard-Link deadline —ACC utilization utilizationReference
deadlineMRFC utilization utilizationReference
deadline controlVariablePcontrolVariableIfeedbackControlSampleTimemissRatioReferencemissRatioControlVariableP
Table 5.6: Variables to set in the DBTrans and UIC_SystemParametersstructs when using aspect packages
the DBTrans pointer is re-pointed to this object (line 9). After the transac-tion is created, the user can submit queries by calling RUIC_Op_Query (line12), using the same pointer used when calling RUIC_Op_beginTransactionand with a string containing the SQL query. RUIC_Op_startTransaction(EOT), called with the DBTrans pointer, is used to start executing thetransaction queries in a new thread (line 13). When the thread has ex-ecuted the queries the result is presented to the user and the transac-tion is rolled back, i.e., freed up internally, before the thread is released.RUIC_Op_cleanup should be called to delete mutexes previously created(line 14).
Observe that this API uses RUIC_Op_startTransaction, instead ofRUIC_Op_commitTransaction, RUIC_Op_printTransaction, and RUIC_Op-_rollbackTransaction. These functions are instead called from the threadcreated when calling RUIC_Op_startTransaction. The RUIC_Op_Init andRUIC_Op_cleanup are further used instead of RTMC_Op_Init.
55
5.6 Debugging
Included in COMET v3.0 is a debugging tool, suitable for debugging amulti-threaded system, like COMET with a concurrency configuration. De-bugging information is written to a file, debug.out, in the root directoryof COMET v3.0. Several different functions exist in the debugger and arelisted in table 5.7.
void initDebug() Initializes the critical section that protects the de-bug output file.
char *getDebugStr() Returns a pointer to the global string debugStr,which is used when printing variable values.
void debugPrint(unsigned
area, const char *str)
Prints a debug message for the given area.
void debugPrintN(unsigned
area, const char *str)
Prints a debug message for the given area. Thefunction does not append a new line.
void errorPrint(const char
*str)
Prints an error message to the standard error out-put.
void debugPrintG(unsigned
area)
Prints the global debugStr string as a debug mes-sage for the given area.
void debugPrintGN(unsigned
area)
Prints the global debugStr string as a debug mes-sage for the given area. The function does notappend a new line.
void errorPrintG() Prints the global debugStr as an error message.void warnPrint(const char
*str)
Prints a warning message to the standard erroroutput.
void warnPrintG() Prints the global debugStr string as a warningmessage to the standard error output.
void leaveDebugCS() Leaves the critical section that protects the debugoutput file.
Table 5.7: Debug functions available in COMET
The area parameter, sent to some of the functions in table 5.7, specifies inwhich component or aspect the debug function call is done. The parameteris internally bitwise compared with a variable named debugComponents,which is specified in the debug header file, and defines from which com-ponents and aspects debug output should be generated. This way one canchoose exactly which debug output should be generated without havingto remove debug function calls from the code. Debug levels exist for all
5.6. Debugging
components, concurrency aspects and one common level for QoS aspectsas can be seen in table 5.8. The debug levels can be combined in any wayto get desired debug output, by setting the debugComponents constant toa bitwise OR (|) of the wanted debug levels, e.g., by setting
static const unsigned debugComponents = D_UIC | D_SMC | D_QOS;
debug output will be generated for the UIC, SMC and QoS aspects.
Level Value DescriptionD NONE 0 Generates no debug outputD UIC 1 Generates debug output for the UICD BMC 2 Generates debug output for the BMCD IMC 4 Generates debug output for the IMCD LMC 8 Generates debug output for the LMCD MMC 16 Generates debug output for the MMCD SMC 32 Generates debug output for the SMCD TMC 64 Generates debug output for the TMCD HP2PL 128 Generates debug output for the HP2PL aspectD QOS 256 Generates debug output for the QoS aspectsD ODC 512 Generates debug output for the ODC aspectD GRD 1024 Generates debug output for the GUARD aspect
Table 5.8: Debug levels available in COMET
Adding Debug Output
To add debug output from a component or aspect the following steps mustbe performed:
1. The initDebug function should be called from the application run-ning COMET to initialize the debugger.
2. The debug.h header file should be included in the component oraspect.
57
3. The debugComponents constant should be changed to include thedesired components and aspects.
4. The debug function calls should be added in the component and as-pect code.
Debugging Variable Values
When a variable value should be included into the debug output, the get-DebugStr function should be pointed to the output string, followed bycalling the debugPrintG function. An example of a debug function callcontaining a variable value from the UIC can be seen below:
sprintf(getDebugStr(),"In Function 1. Value of integer1: %d", integer1);debugPrintG(D_UIC);
Debug Printout
An example of the printout generated from the debugger can be seen below:
[8] DEBUG(64): RTMC_Mech_ReadDataToBuffer done.[2] DEBUG(256): **************SAMPLE TAKEN**************[2] DEBUG(256): UtilizationTarget changed to: 0.951993[5] DEBUG(32): SMC_Op_Completed()
The first digits in a printout line specifies within which SMC thread thedebug function call was done. The second set of digits specify within whichcomponent or aspect the debug function call was done, corresponding to thecomponent or aspect specified in table 5.8. The debug strings are printedlast in the printout line.
5.7 Coding and Naming Standard
This chapter provides a coding and naming standard for development ofcomponents and aspects in the COMET platform. The coding and namingstandard only provides guidelines for enhancing readability and further
5.7. Coding and Naming Standard
development of the COMET platform. It should not be seen as a style-guidefor C programming and therefore it provides no guidelines for the actualcode design with regard to indentation, variable naming, block structuresetc.
5.7.1 Components
This subsection provides a coding and naming standard for componentsin COMET. Currently the coding and naming standard is enforced on allCOMET components, concurrency aspects, and QoS aspects.
Component files
A component in COMET contains the following files:
• Interface header files, contain declarations of all interfaces (opera-tions) of a component. These files are named CompNameInterface.h,e.g., MMCInterface.h.
• Provided interface header files, used during dynamic reconfigurationof COMET, contain declarations of all provided interfaces (opera-tions) used by other components. These files are named CompName-prov interface.h, e.g., MMC_prov_interface.h.
• Required interface header files, used during dynamic reconfigurationof COMET, contain declarations of all required interfaces (opera-tions) needed from other components. These files are named Comp−Name req interface.h, e.g., MMC_req_interface.h.
• Component header files, contain declarations of all component mech-anisms. These files are named CompName.h, e.g., MMC.h.
• Component code files, contain all component operation and mechan-ism definitions. These files are named CompName.c, e.g., MMC.c.
• Component datatypes files, contain all component datatype and datastructure definitions. These files are named CompName datatypes.c,e.g., MMC_datatypes.c.
59
Function Naming
All functions contain a prefix specifying which component it is contained in,e.g., a function, FunctionName, in the TMC component would be calledTMC FunctionName. A FunctionName also has a prefix depending on ifit is a interface (operation) or mechanism:
• Interfaces (operations) are named CompName Op FuncName, e.g.,TMC_Op_FuncName.
• Mechanisms are named CompName Mech FuncName, e.g.,TMC_Mech_FuncName.
• Internal functions that are not mechanisms or operations do not havesuch a prefix, but are instead just named ComptName FuncName,e.g, UIC_lexcond.
In cases where different versions of a function (or component) exist for therelational and database pointer parts, a prefix R or DbP , respectively, isapplied to differentiate between them, e.g., RUIC and DbPUIC.
5.7.2 Aspects
This subsection provides a coding and naming standard for aspects inCOMET.
Aspect files
• Aspect advice files, contain the pointcuts and advice of the aspect.These files are named AspectName.ah.
• Aspect code files, contain the definition of functions used by the ad-vice. These files are named AspectName.c.
• Aspect header files, contain declarations of functions, constants anddatatypes used by the aspect. These files are named AspectName.h.
• Aspect datatypes files, contain all aspect datatype and data structuredefinitions. These files are named AspectName datatypes.c, e.g.,HP2PL_datatypes.c.
5.7. Coding and Naming Standard
• Aspect provided interface header files, used during dynamic recon-figuration of COMET, contain declarations of all provided interfaces(operations) used by components in places where aspect code is woven.These files are named AspectName prov interface.h, e.g., HP2PL-_prov_interface.h.
• Aspect required interface header files, used during dynamic reconfigur-ation of COMET, contain declarations of all required interfaces (oper-ations) needed from components. These files are namedAspectName-req interface.h, e.g., HP2PL_req_interface.h.
In small aspects it is possible to include all aspect functionality (advice andfunctions) into one aspect advice file.
Aspect Naming
• Aspect advice are named AspectName AdviceName, e.g.,HP2PL_readTuple.
• Aspect functions are preferably namedAspectName FunctionName,e.g., HP2PL_InsertItem, although this is not mandatory.
5.7.3 Headers
DOXYGEN [15] headers are provided for both files and functions to gen-erate documentation. The headers available are:
• File headers, are to be included in the interface header files, compon-ent code files and aspect advice files only and contain informationon component/aspect name and also provide both a brief and longdescription of the purpose and functionality. An example can be seenbelow:
/*! \interface ComponentName* \brief Brief description of component/aspect** Long description of component/aspect*/
61
When including a file header in an aspect advice file or a componentcode file, the interface tag is replaced with a file tag.
• Function headers, contain a general description of the function andalso information on function name, parameters, return type and value.All other functions used in the function are also included in a bulletlist. Additionally all functions that provide a join point for any advicein an aspect, should contain the name of that aspect. Function head-ers need only to be added to interfaces (operations) and mechanisms.An example can be seen below:
/*!******************************************************\fn int FunctionName(int arg1)****************************************************** Returns the current number of tuples in the buffer.** @param arg1, used for...* @return Integer, returns value of...** HP2PL** - UsedFunction1* - UsedFunction2*/
• Struct headers, are to be included in the datatype files and aspectheader files only and contain both a brief and long description of thestructs (data structures) used by the component. An example can beseen below:
/*! \struct structName* \brief Data type containing some information** Long description of Struct and its members*/
5.8. Tuple Updates and Deletions
typedef struct attrInfo{int type; /*!< Type of attribute */
} attrInfo;
• Advice headers, are provided for all advice in the aspects implemen-ted. An example of an advice header can be seen below:
/*!* Description of advice functionality.** after/before/around** execution("bool MMC_Inter_Function1(...)") && args(a);** - UsedFunction1* - UsedFunction2*/
The header contains a description of the advice functionality, a linewhether it is woven after, before or around the join point, and alsothe join point where the advice will be woven in. All other functionsused in the advice are also included in a bulleted list.
5.8 Tuple Updates and Deletions
Tuples did not update correctly in COMET v2.0, and therefore neitherCOMET v3.0, when compiled for UNIX. Problems also occurred whendeleting tuples. The following steps were taken to correct these errors:
• Bug fixes which were done in COMET v1.5, were also implementedin COMET v2.0.
• Platform specific compilation directives were added.
• The BMC_Op_intSetXY, BMC_Op_floatSetXY functions did not searchthe buffer array correctly, which has now been corrected.
63
• The RTMC_Mech_condition function could not handle all types ofconditions set in queries, which has now been corrected.
• The UIC_getIfValueOrAttr function could not handle float data-types, which has now been corrected.
• The RTMC_Op_Result function had two lines in the wrong order,which have now been switched.
• A segmentation fault due to corrupt metadata could not be dis-covered, but fixed by a dummy declaration added in RTMC_Op_Result.
With the improvements made above, updates and deletes are performedcorrectly.
5.9 ACCORD and RTCOM Conformance
By enforcing the coding and naming standard on the COMET compon-ents and aspects, and identifying functions as either interfaces (operations),mechanisms or internals, a more clear distinction is made between the dif-ferent types of functions. The different types of functions are now alsoseparated in the component code files, and named according to the namingand coding standard (section 5.7). Although reduced in numbers, some op-erations still call other operations in the same component, and mechanismsin some components still call some operations in other components, whichis not compliant with ACCORD and RTCOM. The section in the COMETUser Manual [21] containing function dependencies, i.e. a reference over allCOMET function calls, can be used to further analyze the functions andfunction calls.
5.10 Data Passing
The new transaction model, initially implemented in COMET v2.0, uses astruct called DBTrans, to store transaction specific information. Before DB-Trans was introduced, the transaction identifier was passed between com-ponents and functions, which resulted in many lookup algorithms to search
5.11. Building COMET and Generating Documentation
for transaction related data. To avoid these time consuming searches, theDBTrans struct is passed instead, and all transaction information can beaccessed immediately, which also aspects can benefit from. When aspectsare woven into the code, they may require certain transaction data, whichwas complicated to obtain before the DBTrans was introduced.
The DBTrans struct should be used by aspects to weave in transac-tion related information the aspect needs to store. If the aspect needsto introduce system related information, these should be woven into theUIC_SystemParameters struct. When creating a large aspect, which needsto store complex aspect related data, the use of internal structs in theaspect is preferred.
5.11 Building COMET and Generating Doc-umentation
A script to build the system is provided with the COMET database plat-form. The script can be used to build the system with any number ofaspect packages applied. Generating documentation on COMET compon-ents, aspects, and data structures is also performed using the script. Moreinformation on how to build COMET is documented in the COMET UserManual [21]. In the COMET documentation, generated by the build script,it is possible to track which functions are used within a certain function,but not the other way around, i.e., from which functions a certain functionis called. For this purpose a small program exists for generating a docu-ment containing these function dependencies, provided that the coding andnaming standard is enforced (see section 5.7).
65
Chapter 6
Dynamic Reconfiguration
Composition enables prefabricated components to be reused by rearrangingthem in new composites [30]. The composition of software components inreal-time systems is typically done at the design stage of the system, whichalso is the case for the current implementation of COMET. To increase up-time and make dynamic reconfiguration of the component system possible,the components could be made swappable during run-time. This impliesthat no shutdown and recompilation of the system has to be done whenplugging in a new component to replace an old version.
6.1 Requirements for Dynamic Reconfigura-tion
To achieve dynamic reconfigurability in a real-time system, certain require-ments, which are described in this section, need to be fulfilled. Two existingcomponent models, ROBOCOP [17] and KOALA [22], and their pros andcons in regard to dynamic reconfigurability, are also described in this sec-tion.
To be able to dynamically reconfigure a real-time system, there existseveral basic requirements which should be fulfilled [8]. A number of re-quirements are mandatory, meaning that without fulfilling them dynamic
6.1. Requirements for Dynamic Reconfiguration
reconfigurability cannot be achieved, while others are optional but desired.The basic requirements are listed in table 6.1. Among these basic require-ments the first two, code mobility (R1) and OS support (R2), are mandatoryrequirements, while R3-R9 are desirable.
6.1.1 Existing Models
In embedded and real-time systems there exist a few component models,e.g, ROBOCOP [17] and KOALA [22], where support for dynamic reconfig-uration is included. This section describes the parts, of these two compon-ent models, which can be applied to the ACCORD and RTCOM extensionsin order to enable dynamic reconfiguration of COMET.
ROBOCOP
ROBOCOP is a component model that includes support for run-time swap-ping of components [17]. The model includes support for dynamic bindingof components using various binding options. ROBOCOP also investig-ates implications of component swapping in terms of reuse of the state ofthe component that is replaced. Internal component import and exportfunctions are introduced to solve these issues. The export function allowsthe component to temporarily store relevant data outside its data space insuch a way that when the new component version is swapped in the saveddata can be retrieved. Two main ways of realizing run-time componentswapping exist in ROBOCOP [17]:
1. A negotiation is performed with the components using interfaces ofthe swappable component that the component is not going to beavailable for a certain time. The component is then replaced whenan agreement has been made.
2. A component is replaced with a new version without communicationwith other components.
Common for the different ways of resolving component swapping in ROB-OCOP is that they introduce some level of function call redirection, e.g.,using a jump table of pointers to redirect communication between the differ-ent components [17]. Regardless of how component swapping is performed,
67
Nr Name DescriptionR1 OS support In order to perform dynamic reconfiguration one needs
support from the operating system. Without the supportof the underlying operating system, it is impossible to con-duct component swapping.
R2 Code mobility New versions of the components should be able to be pre-pared independently of the running system and then re-place stale versions of the components.
R3 Module-basedsoftware struc-ture
Dynamically reconfigurable software should have a modu-lar structure that consists of one or more swappable mod-ules.
R4 Dynamic ex-tensibility
Software upgrading involves possible changes of interfacesand functionality, and the software swapping architectureshould be able to manage and support interface extensionand interface change dynamically.
R5 Managed inter-face access
In conformance with the information hiding principleof component-based software development, the inter-component communication has to be managed to retainthe inter-component relationship after one or multiplecomponents have been swapped. In other words the soft-ware swapping infrastructure has to provide some type ofmiddleware services to manage the components at run-time.
R6 State sensitiv-ity
When swapping one or more components, the compon-ents internal state has to be preserved and restored in thenew component version, thus guaranteeing integrity andcontinuity of the application.
R7 Delay sensitive For real-time systems it is important to prevent that thedynamic reconfiguration violates the availability of the ap-plication. The swapping technique should have a very ef-fective mechanism to minimize application interruption,thus not introducing large delays in execution time.
R8 Minimizingside-effect
The subset of components undergoing dynamic reconfigur-ation should not interfere much with the execution of therest of the system, i.e., when swapping one component,other parts of the system should still be able to execute.
R9 Service trans-parency
The dynamic reconfiguration mechanism should be trans-parent to client applications and no cooperation from theclient side during the process of reconfiguration should berequired.
Table 6.1: Basic Requirements for Dynamic Reconfiguration
6.2. Feasibility
but depending on if OS support (R1) exists, ROBOCOP conforms to themandatory requirements.
KOALA
KOALA is a component model that includes the notion of dynamic late-binding [22]. By using switches, a middleware element that can be used toroute connections between interfaces, KOALA permits binding of compon-ents depending on conditions that are determined at runtime. To achievethis, the binding knowledge is taken out of the components. When commu-nicating between components A and B, component A is said to require aninterface of a certain type and B provides such an interface. What KOALAlacks, in terms of swapping components at run-time, is code mobility (seeR2 in table 6.1).
6.2 Feasibility
The first step in determining if dynamic reconfiguration of COMET is feas-ible to implement on ACCORD and the COMET platform is to examineif the requirements for OS support and code mobility can be fulfilled (R1and R2in table 6.1). There exist a possibility of compiling the COMETcomponents into shared objects or libraries and dynamically linking theselibraries during run-time, e.g., when running UNIX [26]. Hence, by link-ing the shared objects through a component framework middleware, it ispossible to achieve OS support for run-time component swapping.
If we assume that swapping of the components is a predefined taskthat is initiated from the application periodically, it allows us to remotelyprepare new versions of components and then replace stale versions of thecomponents, thus complying with the requirement of code mobility (seeR2 in table 6.1). Since ACCORD originally does not support a componentframework, which should handle all communication between components,extensions need to be made to the ACCORD design method, including theRTCOM component model, to support dynamic reconfiguration.
69
6.3 ACCORD and RTCOM Revisited
The ACCORD design method, in its original specification, does not supportdynamic reconfiguration. Extensions, with regard to introducing a compon-ent framework middleware for routing communication between interfaces(as in KOALA and ROBOCOP), need to be made to enable dynamic re-configuration. Extensions also need to be made to the RTCOM componentmodel to support preservation of component and aspect internal states.The main constituents, which are explained in the paragraps below, of theextended ACCORD design method can be seen in figure 6.1. The specific-ations of the changes made to ACCORD and RTCOM, can be seen as aconformance rule-set, for design and implementation of components andaspects, suitable for component swapping.
ExtendedRTCOM
Component shared objects Aspect shared objects
ACCORDComponentFramework
Interface
Figure 6.1: Extended ACCORD with support for dynamic reconfiguration
ACCORD Component Framework
To enable dynamic reconfiguration ACCORD must be extended with acomponent framework. A component framework can be seen as a middle-ware between the application and components (with woven aspects). Allcommunication between components is handled by, and called through,the component framework. The framework uses a jump table to redirectcommunication between component interfaces, as in the ROBOCOP com-
6.3. ACCORD and RTCOM Revisited
ponent model (see section 6.1.1). When swapping a component the jumptable entries for the component required and provided interfaces are re-pointed to the new version of the component after it has been loaded intomemory. During the dynamic reconfiguration the component frameworktemporarily stores components internal states using the export and importfunctionality of the component (as prescribed by extended RTCOM in thefollowing section). Before swapping a component, the component frame-work must ensure that the component is in a safe state, meaning that notransactions in the system will fail execution during the component swap.The pseudocode for swapping components and storing their internal statesis specified below:
swapComponent(comp1,comp2){int internalStateStorage;if(comp1.componentSafeState()){if(comp1.existInternalState())internalStateStorage=comp1.exportCompState();
redirectJumpTableFunctionPointers(comp1,comp2);if(comp2.existInternalState())comp2.importCompState(internalStateStorage);
}}
RTCOM extensions
Components often maintain an internal state, e.g., global variables. To beable to preserve the internal state of a component, when swapping it foranother version, RTCOM needs to be extended with operations in providedinterfaces for exporting and importing internal states. The export functionenables the component to temporarily store relavant data outside its dataspace (in the component framework), in such a way that, when the newcomponent version is swapped in, the saved data can be retrieved.
Aspects generally cross-cut several components and need to provide acommon internal state, e.g., global variables, for all components. Whenswapping a cross-cut component the aspects internal state must be pre-served, thus making it necessary to store the aspect internal state in the
71
components. For this reason the aspects in RTCOM need extensions toallow an aspect to consist of two elements, one aspectual element and oneshared element. The aspectual element of the aspect contains advice whichis woven into components and can be dynamically changed. The shared ele-ment of an aspect contains parts of the aspect which needs to be common toall components. Since communication between components and the sharedelement of an aspect is handled by the component framework, the sharedelement needs provided and required interfaces. In cases where an aspectonly cross-cuts one single component, the whole aspect can be includedinto the cross-cut components shared object. The RTCOM extensions foraspects are therefore, dependent of aspect implementation.
6.3.1 Requirement Conformance
In this section the extensions made to ACCORD and RTCOM are analyzedby examining how well they conform with the requirements in table 6.1.Extended ACCORD provides a component framework middleware, whichcomponents plug in and out of. By using this framework and a communic-ation redirection jump table our solution conforms with the requirementof managed interface access (R5 in table 6.1). The component frameworkon the other hand does not allow extensions to component interfaces, thusnot supporting the optional requirement of dynamic extensibility (R4 intable 6.1). In regard to other optional requirements for achieving dynamicreconfiguration, extended ACCORD complies with some but others not.Using RTCOM, ACCORD fulfills the requirement of module-based soft-ware structure (R3 in table 6.1). The component framework is delay sens-itive (R7 in table 6.1) since, by using a jump table and only redirectingcalls to other components interfaces, a low time cost, relative to the re-sponse time of the application, for swapping a component is achieved. Thedelay in execution introduced when swapping a component mainly consistsof the time it takes to store and restore the components internal state.When swapping a component which has an internal state that must be re-stored after the swap has taken place, the extended RTCOM componentsexport and import functions are provided to assure state sensitivity (R6 intable 6.1). By assuming that swapping of the components is a predefinedtask that is initiated from the application periodically, ACCORD does not
6.4. Dynamic Reconfiguration of COMET
comply with the requirement of service transparency (see R9 in table 6.1).The requirement of minimizing side-effects (R8 in table 6.1), is implement-ation specific since it depends on how the system is ensured to be in a safestate before a component swap, and therefore the ACCORD extensions donot influence this requirement.
6.4 Dynamic Reconfiguration of COMET
The COMET swapping architecture represents the implementation of AC-CORD dynamic reconfiguration and consists of three main parts (see fig-ure 6.2):
1. The COMET Component Framework (CCF) is the focal point of theswapping architecture. The framework acts as a middleware betweencomponents (with woven aspects) and the application. All commu-nication (arrows in figure 6.2) between components, application anddebugger is handled by, and called through, the CCF. The imple-mentation details of the CCF are described in section 6.4.1.
2. The components in the swapping architecture are compiled into sharedobjects and dynamically linked into the CCF to allow new versions ofthe component to be plugged into COMET. Detailed information oncomponent changes, to conform to extended RTCOM, is given in sec-tion 6.4.2. The debugger is also compiled into a shared object of itsown to allow all components to use its functionality. Specifications onchanges made to the debugger, using CCF, are given in section 6.4.2.
3. The aspects, as in a COMET configuration without using CCF, areprecompiled to cross-cut the different components. In order to con-form to the extended RTCOM model, adaptions had to be madeto the concurrency control and QoS management aspects (see sec-tion 6.4.3).
To add new components and aspects, and make them swappable usingCCF, they should be implemented in a way that they comply with theextended RTCOM.
73
aspectsCC QoS
aspects
UIC TMC SMC DebugAppHP2PL...
COMET Component Framework (CCF)
Figure 6.2: Architecture of COMET Component Swapping
6.4.1 COMET Component Framework
The COMET Component Framework (CCF) is implemented in C and con-sists of a code file and a header file. The first part of the CCF code filedeclares handles for all shared object files, corresponding to COMET com-ponents, it needs to open. Function pointers, within jump tables, to allinterface functions provided and required by any COMET component, arealso declared. The CCF focal point is the main function which has thefollowing code:
int main(){
1. initCOMET();2. initDebug();3. cometcall();
return TRUE;}
The main function initializes COMET (line 1) by pointing all interfacefunction pointers into the shared object files of all the components. Toachieve this, the component framework uses the dlopen and dlsym func-tions provided by the dlfcn.h header file for dynamic linking of shared
6.4. Dynamic Reconfiguration of COMET
objects [23]. The debugger, being a shared object of its own is initializedfor the whole COMET configuration by calling the initDebug function(line 2). The last function call, cometcall (line 3) starts the execution ofthe application using the COMET database.
The CCF also provides the application with a function for swapping thedifferent COMET components. The swap() function can be called from theapplication, by including the CCF header file, to regularly check for newversions of a component and, if a new versions exists, automatically swapit. The CCF internally holds a version number of the component versionsin the current configuration, and when a new version is compiled into therun-time directory, the component is swapped. More information on thistopic can be found in the COMET User Manual [21].
6.4.2 Component Changes
To be able to plug COMET components in and out of the CCF, some ex-tensions have to be made to the component specification. All componentsneed to, beside the standard interface header file, also provide one requiredand one provided interface file. Additionally all component code files needto have precompiler directives stating which of the interfaces should beused during AspectC++ precompilation, for weaving aspect code and theg++ compilation of the COMET component shared objects, respectively.During precompilation the standard interface files should be included, oth-erwise join points will not match function definitions and calls in componentcode. On the other hand, while compiling the COMET component sharedobjects, the required and provided interfaces need to be included to makethe component interfaces accessible from CCF. Therefore the -D CCF flagis added during the g++ compilation. An example of such precompilerdirectives in a component code file, in this case UIC.C, can be seen below:
/* UIC.C */#ifdef CCF#include"../UIC_req_interface.h"#include"../UIC_prov_interface.h"#include"../debug_req_interface.h"#else
75
#include"../UICinterface.h"#include"../debug.h"#endif
Provided Interfaces
The reason for needing a separate provided interface, containing almost thesame code as the standard interface file, is because of problems using thedlfcn.h header file with the g++ compiler. The difficulties of loading aC++ library dynamically are partially due to name mangling [16]. In everyC++ program (or object file), all non-static functions are represented in thebinary file as symbols. These symbols uniquely identify a function in theprogram or object file. In C, the symbol name is the same as the functionname. This is possible because in C no two non-static functions can havethe same name. Because C++ allows overloading and has many featureswhich C does not have, e.g. classes, member functions and exceptions, it isnot possible to simply use the function name as the symbol name. To solvethat, C++ uses so-called name mangling, which transforms the functionname and all the necessary information into an internal symbol name. Thisleads to problems when trying to bind the function pointers in the CCFwith the correct functions, i.e., the symbol cannot be found. To solve this,all interfaces in the provided interface header of a component are declaredas extern "C", which tells the g++ compiler to use C-type symbol names.An example of a provided interface file is given below:
#ifndef _UIC_PROV_INTERFACE_#define _UIC_PROV_INTERFACE_#include "UICdatatypes.h"extern "C" bool RUIC_Op_beginTransaction(DBTrans ** trans);extern "C" bool RUIC_Op_commitTransaction(DBTrans * trans);#endif
Required Interfaces
The reason for needing a required interface file is that since the componentsthat provide interfaces to a certain component can be swapped. Therefore,a components required interfaces need to be function pointers, which can
6.4. Dynamic Reconfiguration of COMET
be repointed by the component framework to another component version.The required interfaces are also, for the same reason as provided interfaces,declared as extern "C". An example of a provided interface file is givenbelow:
#ifndef _UIC_REQ_INTERFACE_#define _UIC_REQ_INTERFACE_#include "TMCdatatypes.h"extern "C" bool (*RTMC_Op_getResult)(ParseTree *, Btable *);extern "C" bool (*RTMC_Op_removeBuffer)(Btable *);#endif
Debugger Changes
The debugger, included in the COMET platform, requires changes similarto the ones of components to work when running COMET with CCF. Sincethe debugger is intended for debugging multiple transactions running inseparate threads, but using a common output file, it internally uses mutexesto protect debug output prints. Because of this the debugger must becompiled into a shared object of its own, and its functions be declared asprovided interfaces for all the other components and aspects. The debugcode file uses precompiler directives to use the debugger standard headerfile when using COMET without CCF, and the debugger provided interfaceheader when running COMET with CCF. The precompiler directives canbe seen below:
#ifdef CCF#include "../debug_prov_interface.h"#else#include "../debug.h"#endif
When calling debugger functions from a component or aspect, the debuggerstandard header file should be included during the AspectC++ precompil-ation of aspects, and the debugger required interface file should be includedwhile compiling the component shared objects. An example of this, fromthe UIC.C file, can be seen in section 6.4.2 above.
77
6.4.3 Aspect Changes
When running COMET with a concurrency and/or QoS management con-figuration, the aspect code is generally woven during the AspectC++ pre-compilation. If the CCF is added to the configuration some other adaptionsof the aspects are needed to ensure aspect functionality. In cases where as-pects need to provide a common internal state, e.g., if it performs someinitialization of mutexes or has some global variables, those parts of theaspect need also to be compiled into a shared object of its own. The reasonfor this is that if the object file generated from the aspect code and aspectheader files, is included into all shared object files of components. The dif-ferent components will therefore each have a separate instance of the aspectobject file, thus also having a separate instance of, e.g, all global variables.A more detailed description of the solutions to this problem can be foundin the HP2PL and QoS aspects and components paragraphs below.
GUARD
The GUARD aspect has been modified to function correctly with the CCF.Join points have been changed such that all aspect code is woven into onesingle component, the SMC. These changes do not change the GUARDfunctionality, but weaves code on execution of functions instead of on callsto the functions. The benefit of changing these join points, is that by onlyincluding the GUARD object file into the SMC shared object, GUARDfunctionality is assured. A major drawback with this approach though,since the GUARD aspect contains mutexes and global variables, is that theSMC component cannot be swapped during run-time when using GUARD,since the values of the global variables will not be restored when a newversion of the SMC shared object file is swapped into the system.
There exist two solutions to this problem. One solution, applied on theHP2PL aspect, is to compile parts of the aspect into an own shared objectfile. This solution is the preferable one when an aspect cross-cuts severalcomponents. Another solution, suitable for aspects which only cross-cut asingle component (applied on the QoS aspects below), is to weave in codeinto the component internal state export and import functions.
6.4. Dynamic Reconfiguration of COMET
HP2PL
The HP2PL aspect cross-cuts several components and has both mutexesand global variables, containing information on locking and index opera-tions, which need to be common for all the cross-cut components. There-fore, the aspect header and code file need to be compiled into an own sharedobject file with its own provided and required interfaces. The shared ob-ject part of the aspect is very similar in structure to a component sharedobject, having the same types of interfaces specified in the same way as forthe components (see section 6.4.2).
The aspect advice file has been changed and should be implemented ina way that the advice code, which should be woven in at a certain joinpoint, should only be a call to a interface in the aspect shared object file.By implementing the aspect advice in this manner and generating a sharedobject file for all aspect functionality, advice can still be woven in while thecomponents can use a common instance of aspect variables. Inclusions ofthe different HP2PL interface header files, is also conducted in a similar wayof how it is done for components (section 6.4.2). The aspect files neededfor HP2PL are listed below, and can be seen as a template for which filesare needed to provide an aspect with support for component swapping:
• The HP2PL advice file, hp2pl.ah, contains all point-cut expressionsand corresponding calls to interface functions of the HP2PL sharedobject.
• The HP2PL header file, hp2pl.h, contains declarations of all func-tions of the aspect shared object that are not interfaces.
• The HP2PL code file, hp2pl.c, contains definitions of all functionsof the aspect shared object that are not interfaces.
• The HP2PL datatypes file, hp2pl_datatypes.h, contains declara-tions of all datatypes of the aspect shared object.
• The HP2PL interface file, hp2pl_interface.h, contains definitionsof all interfaces of the aspect shared object.
79
• The HP2PL required interface header file, hp2pl_req_interface.h,contains definitions of all interfaces, required from components, withinthe aspect shared object.
• The HP2PL provided interface header file, hp2pl_prov_interface.h,contains definitions of all interfaces, provided to components, by theaspect shared object.
• The HP2PL required includes header file, hp2pl_req_includes.h,contains function pointers to all interfaces provided from HP2PL.This file should, to enable components to call the provided interfacesof the aspect shared object, be included into the required interfaceheader files of the components that are cross-cut by the aspect.
QoS aspects and components
The ACC and MRFC QoS management configurations are implementedusing two components (QAC and FCC) and five aspects (QACA, FCCA,TRTA, MDMA, and UMCA). All these components and aspects are imple-mented in such a way that, after restructuring of code during the COMETmerging and improvements (chapter 5), they only cross-cut functionalityin the SMC component. The easiest way to run these QoS managementconfigurations with COMET and CCF is therefore including all object filesgenerated from these components and aspects into the SMC shared objectfile. Since the QoS objects only call internal functions and SMC functions,no extensions to the SMC interface header files are necessary.
The problem with this solution arises when the SMC component isswapped with another version of the component, since the QoS componentsand aspects have some global variables that need to be restored after theswap. The solution for this is weaving in code into the SMC componentexport and import functions. This code exports the values of the globalvariables, before the SMC component is swapped, and imports them againwhen the new SMC shared object is in place. A more detailed descriptionon saving and restoring component internal states is given in section 6.4.5below.
6.4. Dynamic Reconfiguration of COMET
6.4.4 COMET Safe State
When swapping a component, it is vital that the component currently is notexecuting any transactions. To ensure that this is the case, two interfaceshave been added to the SMC, which empty the active queue of transactionsbefore swapping any component and initiate execution of transactions afterthe swap has taken place. This solution, though, heavily violates the R8requirement in table 6.1, since no transactions are allowed to run while acomponent is being swapped. The pseudocode for these two functions islisted below:
void SMC_Op_EmptyActiveQueue(){
StartSwap = true;while (ActiveQueue_length == 0)_usleep(1000);}
void SMC_Op_FillActiveQueue(){for(int j=0;j<MAX_NOF_TRANSACTIONS;j++){SMC_Node* start = SMC_Mech_getNextToExecute();if (start != NULL)SMC_Mech_Start(start,(void *)SMC_Mech_startTransactionByThread);else break;
}StartSwap = false;
}
Since the FCC component is compiled into the shared object file of theSMC, the thread running the feedback control loop in FCC must be ter-minated before swapping SMC. For this reason new advice has been addedto weave the function call to terminate this thread after the ready queueof the SMC has been exported:
advice execution("int SMC_Op_exportReadyQueue(...)"): after()
81
{while(!FCC_Op_Swap()){}
}
The FCC_Op_Swap function, which has been added to the FCC compon-ent, initializes swapping of the FCC and returns when the thread runningthe feedback control loop has been terminated. The function running thefunction control loop, FCC_Mech_feedbackControlLoop, has been modifiedfor enabling thread termination. The code specifying the modifications ofthese functions is listed below:
bool FCC_Op_Swap(){
if(StartSwapFCC==false)StartSwapFCC = true;return EndSwapFCC;
}
void FCC_Mech_feedbackControlLoop(){...while (true){...QAC_Op_adjust(utilizationChange);if(StartSwapFCC){ //Enable FCC Swapping
EndSwapFCC=true;_ExitThread(0);
}}
}
6.4.5 Saving Component States
Some of the COMET components, MMC, TMC, and LMC, have no in-ternal state that needs to be exported before swapping them with a newversion of the component. For the other components, UIC, IMC, and SMC,
6.4. Dynamic Reconfiguration of COMET
there exist internal structures and variables that need to be exported be-fore swapping and restored thereafter. For example, the UIC maintains aninternal array of all current transactions running in the database, the IMCstores addresses where all metadata and tuples are stored in memory, andthe SMC maintains a list of all transactions that are either scheduled torun or currently running in COMET. The UIC and IMC currently haveno functionality for exporting and importing their internal states, but forthe SMC such functions are implemented. The remainder of this sectiondescribes the implementation of exporting and importing the queue of sub-mitted transactions in the SMC component.
SMC export and import functions
Before swapping the SMC component to a new version, the queue of sched-uled, but not started, transactions must be temporarily stored in the CCF.After the new version of SMC has been plugged into the CCF, the transac-tion queue should be restored in the new component version. For the CCFto be able to perform this task, the SMC must provide interface functionsfor export and import of the transaction queue. Three such functions areimplemented and specified in the SMC provided interface header file:
• The UIC_SystemParameters SMC_Op_exportSystemParameters()function exports the UIC_SystemParameters struct, which is initiallysent from the application running COMET.
• The int SMC_Op_exportReadyQueue(SMC_Data q[]) functionexports the ready queue of the SMC transactions and returns thenumber of transactions exported. The parameter sent with the func-tion will contain the actual array of transaction after execution ofthe call. The export function also guarantees that the system is in asafe state for swapping, before conducting an export, by allowing alltransactions in the SMC active queue of to terminate.
• The bool SMC_Op_importReadyQueue(SMC_Data q[], int i) func-tion imports the ready queue into the SMC after the new versionhas been swapped into CCF. The import function also schedules andstarts as many transactions as possible, without exceeding the max-imum number of concurrent transactions allowed in the system.
83
Aspect modifications
Since the QoS aspects weave new attributes into the UIC_SystemParametersstruct, the internal state of the QoS aspects is also saved when the func-tion SMC_Op_exportSystemParameters() is executed. The only attrib-ute in the UIC_SystemParameters struct, which does not have a constantvalue, the total estimated utilization, teu(k), is saved by adding new adviceto QACA and weaving code into the SMC_Op_exportSystemParameters()function. When the new version of the SMC component has been pluggedinto CCF the UIC_SystemParameters struct values can be restored. Spe-cification of the QACA advice for saving the total estimated utilization, incode denoted utilizationTarget, is listed below:
advice execution("% SMC_Op_exportSystemParameters(...)"): after(){(((UIC_SystemParameters *)tjp->result()))->utilRef =
utilizationTarget;}
CCF implementation
The swapSMC function in the CCF is called internally when the applicationhas called CCF for a swap of the SMC component. A code listing of theswapSMC function can be seen below:
bool swapSMC(char * filename) {1. UIC_SystemParameters sp;2. SMC_Data rq[MAX_NOF_TRANSACTIONS];3. int nrOfReadyTrans;
4. sp = (*SMC_Op_exportSystemParameters)();5. nrOfReadyTrans = (*SMC_Op_exportReadyQueue)(rq);
6. dlclose(handleSMC);7. initSMC(filename);
6.4. Dynamic Reconfiguration of COMET
8. (*SMC_Op_constructor)(sp);9. (*SMC_Op_importReadyQueue)(rq, nrOfReadyTrans);
return true;}
In lines 1, 2 and 3 variables for temporarily storing SMC internal variablesare created. In line 4 the sp variable is set to the exported UIC_SystemParameters struct from the SMC by calling SMC_Op_exportSystemParameters.Line 5 sets the variable nrOfReadyTrans to the number of current trans-actions in the SMC ready queue by calling SMC_Op_exportReadyQueue,and the actual queue of transactions is stored in the rq array. The actualswap between the component versions is done in lines 6 and 7. The dy-namic link to the old SMC shared object file is first closed, and the newversion of the SMC shared object file is then initialized. By calling theSMC_Op_constructor function with the sp object as parameter, in line 8,the new SMC version is initialized with the previously saved values of theUIC_SystemParameters struct. Finally, in line 9 the ready queue of theSMC is imported using the SMC_Op_importReadyQueue function.
85
Chapter 7
Adaptive FeedbackControl
This chapter contains the design and implementation of the Adaptive Feed-back Control-Miss ratio-Self Tuning Regulator (AFC-M-STR) and Ad-aptive Feedback Control-Miss ratio-Regression Model (AFC-M-RM) al-gorithms. Detailed descriptions of the Adaptive Regression Model Aspect(ARMA) and Self Tuning Regulator Aspect (STRA) implementing the al-gorithms are also given.
7.1 Adaptive QoS Configurations
Two different adaptive QoS management configurations can be used withCOMET. Both configurations require the use of all ACC and MRFC com-ponents and aspects (see section 4.3.2). The Self Tuning Regulator Con-figuration (STRC) additionally needs the Self Tuning Regulator Aspect(STRA) (section 7.2.1), and the Regression Model Configuration (RMC)needs the Adaptive Regression Model Aspect (ARMA) (section 7.2.2). Fig-ure 7.1 presents the composition of software, including components andaspects, when using either one of the adaptive QoS configurations. Thefigure also depicts in which components the different aspects weave code.
7.2. Adaptive Feedback Control Design
LMC
� � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � � � � �
� � � � � � � � �� � � � � � � � �� � � � � � � � �� � � � � � � � �
� � � � � � � � �� � � � � � � � �� � � � � � � � �� � � � � � � � �
� � � �� � � �� � � �� � � �
� � � �� � � �� � � �� � � �
� �� �� �� �� �� �� �� �� �� �
� � � � � � � �� � � � � � � �� � � � � � � �
� � �� � �� � �� � �� � �� � �
� � � �� � � �� � � �� � � �
� � �� � �� � �� �� �� � � � �� � �� � �� � �
� � �� � �� � �� � �
� � �� � �� � �� � �� � � �
� � � �� � �� � �
� � � � � � � � �� � � � � � � � �� � � � � � � � �� � � � � � � �� � � � � � � �
� � �� � �� � �� � �� � �
� � � � �� � � � �� � � � �� � � � �� � � � �� � � � �
� � �� � �� � �� � �� � �� � �
! ! ! !! ! ! !! ! ! !
" " "" " "" " "" " "" " "" " "" " "" " "" " "" " "" " "
# # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # #
$ $ $ $$ $ $ $$ $ $ $$ $ $ $$ $ $ $$ $ $ $
% % %% % %% % %% % %% % %% % %
& & & & & & & && & & & & & & && & & & & & & &' ' ' ' ' ' ' '' ' ' ' ' ' ' '' ' ' ' ' ' ' '
( (( (( (( (( (
) )) )) )) )) )
UIC
SMC
QAC
FCC
TMC
IMCMMC
Compositionaspects
TRTA
QACA
FCCA
MDMA
UMCA
STRA alt. ARMA
Figure 7.1: Software composition of QoS aspects
7.2 Adaptive Feedback Control Design
Adaptive feedback control , as shown in figures 7.2 and 7.3, consists offour parts: a transaction model (see section 2.2.2), a set of control relatedvariables, a controlled system and an adaptive feedback controller. Thecontrol related variables include:
• Controlled variable, m(k).
• Manipulated variable, teu(k).
• Controller tuning variables, i.e., variables for adapting the controllerto workload variations and changes to the database configuration.
7.2.1 Self Tuning Regulator Control
Background on self tuning regulators can be found in section 2.9.1. Herewe discuss the design and implementation of the self tuning regulator usedin this thesis. In every sample a new Ga is estimated according to (2.10).With the transfer function (2.8) and given pole placement, a new KPM
87
can be calculated with (2.9). After KPM is recalculated, the feedbackcontroller is updated with the new value of KPM . For each sample taken,the following steps are executed (numbers correspond to figure 7.2):
1. The Monitor measures the controlled variable, m(k), and forwards itto the Controller Tuner and to the Controller.
2. The total estimated utilization, teu(k), for the last sample is given tothe Controller Tuner.
3. A new Ga(k + 1) is estimated and calculation of a new KPM (k + 1)is performed. The new KPM (k + 1) is then used in the Controller.
4. The Controller compares the reference level, MS , with correspond-ing controlled variable, m(k), and computes a change in the totalestimated utilization, teu(k + 1).
5. The Actuator changes the manipulated variable based on the changein the total estimated utilization. The basic scheduler admits trans-actions, using EDF, according to (2.4).
The KPM value will hence be tuned for better feedback control perform-ance.
STRA advice and functions
This section describes the design of the aspect implementing the AFC-M-STR algorithm in COMET. The implementation consists of one singleaspect, STRA, containing several advice and functions which are describedin detail. The design has been made to conform to the extended ACCORDdesign method and RTCOM component model, guaranteeing that STRAcan be used during dynamic reconfiguration of COMET (see chapter 6).Below all STRA advice are presented, including their join points, advicetype (call, execution or introduction), advice execution point (before, afteror around), advice parameters, and advice functionality. The section alsodescribes all STRA functions used in the aspect, including function para-meters and return values. The STRA aspect is implemented using 4 advicein total. It crosscuts the SMC and FCC, and uses the QAC.
7.2. Adaptive Feedback Control Design
Advice STRA Intro GaJoin Point -Type IntroductionExecuted -Parameters -Functionality Extend the UIC_SystemParameters struct with
Ga.
Advice STRA InitJoin Point FCC_Op_InitType ExecutionExecuted AfterParameters UIC_SystemParameters systemParametersFunctionality Initializes the STRA aspect by introducing float
Ga and float oldUtilizationTarget.
Advice STRA SwapJoin Point SMC_Op_exportSystemParametersType ExecutionExecuted AfterParameters -Functionality Stores the values of the controller parameter in
the UIC_SystemParameters struct before a swapof the SMC component is performed.
Advice STRA UpdateControlVariablePJoin Point FCC_Mech_calculateOutputType ExecutionExecuted BeforeParameters float currentUtilizationOrMissRatioFunctionality Calculates a new control variable P, which is done
by first storing the current miss ratio, and thenthe total estimated utilization. If there are anytransactions in the ready and active queue, thecalculation is performed.
89
Function STRA Op UpdateControlVariablePParameters -Return value bool, Returns true if the algorithm succeeded,
false otherwise.Functionality Estimates a new Ga, calculates a new control
variable (KPM ), and update the control vari-able used by the UMCA aspect (missRatioCon-trolVariableP).
Function STRA Mech EstimateGaParameters float* GaReturn value bool, Returns true if the algorithm succeeded,
false otherwise.Functionality Estimates a new Ga.
Function STRA Mech CalculateControlVariablePParameters float* KpReturn value bool, Returns true if the algorithm succeeded,
false otherwise.Functionality Calculates a new control variable (KPM ).
7.2. Adaptive Feedback Control Design
ControlledVariables
Controller
VariablesTuning
Tuner
Controller
SchedulerBasic
1Monitor
ActuatorAC
Scheduling
Controller
CPU
Reference
Completed/Aborted
Current
-1
Transactions
Transaction Arrivals
Transactions
ManipulatedVariables
2
3
4
5
Controlled System
Figure 7.2: Architecture of adaptive feedback control using a self tuningregulator
7.2.2 Least Squares and Regression Models
Background on least squares and regression models can be found in sec-tion 2.9.2. We describe an estimation of the process model (see figure 7.3)as a difference equation, according to equation (2.11), as
m(k) + a1m(k − 1) + a2m(k − 2) = b0dM (k) + b1dM (k − 1) (7.1)
where k is a sample taken, dM (k) is the manipulated variable which hasbeen applied to the system (4 in figure 7.3) and m(k) is an estimation of thecontrolled variable observed (2 in figure 7.3). We introduce the estimatedparameter vector,
θ(k) = (a1(k) a2(k) b0(k) b1(k))T
91
ControlledVariables
Tuner
Controller
Controller
VariablesTuning
1
3
2
54
5
Monitor
ActuatorAC
Scheduling
Controller
CPU
Reference
Completed/Aborted
Current
-1
Transactions
Transaction Arrivals
Transactions
ManipulatedVariables
BasicScheduler
Process
Model
Adjustment
Mechanism
6
-
+
7
Controlled System
Figure 7.3: Architecture of adaptive feedback control using a regressionmodel
and the regression vector
ϕT (k) = (−m(k − 1) −m(k − 2) dM (k) dM (k − 1)).
A prediction of miss ratio in the kth sampling instant is calculated accordingto equation 2.13 as
m(k) = ϕT (k)θ(k − 1). (7.2)
The open-loop transfer function of the process model, G(z), can be writtenas
G(z) =B(z)A(z)
7.2. Adaptive Feedback Control Design
where
A(z) = 1 + a1z−1 + a1z
−2
and
B(z) = b0 + b1z−1.
The corresponding transfer function for the closed-loop system, Gc(z), canbe written as [12],
Gc(z) =KPMB(z)
A(z) +KPMB(z)=
KPM (b0 + b1z−1)
1 + a1z−1 + a2z−2 +KPM (b0 + b1z−1)(7.3)
For each sample taken, the following steps are executed (numbers corres-ponding to figure 7.3)
1. The Monitor measures the controlled variable, m(k).
2. The Process Model generates an estimation of the controlled variable,m(k), and feeds it to the Adjustment Mechanism.
3. The prediction error (2.14) of the controlled variable is calculated andfed to the Adjustment Mechanism.
4. The manipulated variable, dM (k), is fed to both the Process Modeland Adjustment Mechanism.
5. The Adjustment Mechanism calculates new estimates of the para-meter vector, θ, using RLS (algorithm 2.15), and feeds the parametervector to the Controller Tuner and Process Model.
6. The Controller Tuner calculates new controller parameters dependingon desired pole placement and based on the transfer function for theclosed-loop system, Gc(z), see equation (7.3).
7. The Actuator changes the manipulated variable based on the changein the total estimated utilization. The basic scheduler admits trans-actions, using EDF, according to (2.4).
93
ARMA advice and functions
This section describes the design of the aspect implementing the AFC-M-RM algorithm in COMET. The implementation consists of one singleaspect, ARMA, containing several advice and functions which are describedbelow in detail. The design has been made to conform to the extendedACCORD design method and RTCOM component model, guaranteeingthat ARMA can be added used during dynamic reconfiguration of COMET(see chapter 6). Below all ARMA advice, including their join points, advicetype (call, execution or introduction), advice execution point (before, afteror around), advice parameters, and advice functionality are described. Thesection also describes all ARMA functions used in the aspect, includingfunction parameters and return values. The ARMA aspect is implementedusing 7 advice in total. It crosscuts the SMC, FCC, and QAC.
Advice ARMA Intro ParameterVectorJoin Point -Type IntroductionExecuted -Parameters -Functionality Extend the UIC_SystemParameters struct with
an array for storing the parameter vector θ(k).
Advice ARMA Intro RegressionVectorJoin Point -Type IntroductionExecuted -Parameters -Functionality Extend the UIC_SystemParameters struct with
an array for storing the regression vector ϕ(k).
7.2. Adaptive Feedback Control Design
Advice ARMA Intro PMatrixJoin Point -Type IntroductionExecuted -Parameters -Functionality Extend the UIC_SystemParameters struct with
an 2-dimensional array for storing the P matrixused in RLS algorithm.
Advice ARMA UtilizationChangeJoin Point QAC_Op_adjustType ExecutionExecuted BeforeParameters float utilizationChangeFunctionality Provides ARMA with utilization change for the
next sample.
Advice ARMA RLSJoin Point FCC_Mech_calculateOutputType CallExecuted BeforeParameters float currentUtilizationOrMissRatioFunctionality Calls the ARMA_Op_RLS function, with the miss
ratio, m(k), as a parameter. ARMA_Op_RLS is themain function for executing RLS (see algorithm2.15). Provides ARMA with miss ratio for thecurrent sample, when used in conjunction withUMCA.
95
Advice ARMA InitJoin Point FCC_Op_InitType ExecutionExecuted AfterParameters UIC_SystemParameters systemParametersFunctionality Initializes (or restores after a swap of the SMC
component) the global variables in ARMA con-taining the regression and parameter vectors.The value of the controller parameter is restoredwhen the FCC component is reinitialized.
Advice ARMA SwapJoin Point SMC_Op_exportSystemParametersType ExecutionExecuted AfterParameters -Functionality Stores the values of the global values contain-
ing the regression and parameter vectors in theUIC_SystemParameters struct before a swap ofthe SMC component is performed. The value ofthe controller parameter is also exported.
7.2. Adaptive Feedback Control Design
Function ARMA Op RLSParameters float missRatioReturn value bool, Returns true if the algorithm succeeded,
false otherwise.Functionality The main function for execution of the AFC-M-
RM algorithm using RLS. Its tasks are
1. Calculate miss ratio estimation, m(k), ac-cording to equation 2.13, and store in re-gression vector.
2. Call ARMA_Mech_InsertUtilizationChangefor saving utilization change, which is usedin the next sample.
3. Calculate prediction error, ε(k), accordingto equation 2.14.
4. Calculate parameter vector estimations,θ(k), according to the RLS algorithm(2.15).
5. Calculate controller parameter, KPM , usingthe desired pole placement and based on thetransfer function for the closed-loop system(equation 7.3).
Function ARMA Mech InsertMissRatioParameters float missRatioReturn value bool, Returns true if the miss ratio estimation was
inserted, false otherwise.Functionality Inserts an estimation of miss ratio into the regres-
sion vector.
97
Function ARMA Mech InsertUtilizationChangeParameters float utilizationChangeReturn value bool, Returns true if the utilization change was
inserted, false otherwise.Functionality Inserts the utilization change into the regression
vector.
Function ARMA Mech CalcEstimatedMissRatioParameters -Return value float, Returns the estimated miss ratio.Functionality Calculates a new miss ratio estimation.
Function ARMA Mech CalcPredictionErrorParameters -Return value float, Returns the prediction error.Functionality Calculates the prediction error.
Function ARMA Mech CalcThetaEstimationsParameters -Return value bool, Returns true if the parameter estimations
were calculated, false otherwise.Functionality Calculates estimations of θ(k) and stores them in
the parameter vector.
Function ARMA Mech CalcControllerParameterParameters -Return value bool, Returns true if the controller parameter
value was updated, false otherwise.Functionality Calculates and updates a new controller para-
meter value, KPM .
7.2. Adaptive Feedback Control Design
99
Chapter 8
Performance Evaluation
This chapter contains the performance evaluation experiments done inCOMET v3.0. Section 8.1 describes the database experiment setup andalso describes experiment aspects used for performance evaluation. Sec-tion 8.2 present the execution time analysis performed on SELECT and UP-DATE transactions and also the execution times of the dynamic reconfigura-tion mechanism. Feedback control performance experiments are describedin section 8.3. In section 8.4 the impact of chosen sampling period ondeadline miss ratio is evaluated. The self tuning regulator is evaluated insection 8.5. In section 8.6, dynamic reconfiguration is used to evaluatethe performance of the adaptive feedback configurations in a time-varyingsystem. An experiment examining the transient performance of regularfeedback control, using different controller parameter values, is discussedin section 8.7. Last, in section 8.8, conclusions from the performance eval-uation experiments are drawn.
Goal
The goals of the performance evaluation experiments are to:
• Run transaction execution time experiments to evaluate COMETv3.0in comparison to COMETv1.5.
8.1. Experiment Setup
• Run transaction execution time experiments to evaluate the CCF andmechanism for dynamic reconfiguration.
• Evaluate the addition of a feedback control loop to COMET.
• Evaluate the addition of an adaptive feedback control loop to COMETin comparison to a regular feedback control loop.
• Evaluate the impact dynamic reconfiguration of COMET has ondeadline miss ratio.
8.1 Experiment Setup
For all performance evaluation experiments COMET is configured with theHP2PL concurrency control aspect. Before each experiment run, ten rela-tions are created in the database, each relation consisting of ten tuples. Tocreate a load during the experiment runs, SELECT transactions are createdand submitted to the database with an average inter-arrival time, AI. Toapply different loads the average inter-arrival time, AI, is altered. To re-duce the domino effect caused by the EDF scheduler, the variation in AIis increased by uniformly distributing it in an interval [AI − 20 ms,AI +20 ms]. The transaction deadlines are also uniformly distributed in aninterval Di = [3 · AEi ms, 17 · AEi ms], thus giving the transactions anaverage deadline of Di = (10 · AEi ms). To be able to decide the dead-line for a transaction, execution time measurements for different type oftransactions are performed to obtain AEi (see section 8.2).
Experiment Aspects
The aspects used during the performance evaluation experiments are thefollowing:
• The DeadlineMonitor aspect samples the system when there is nofeedback loop. This experiment aspect only works in conjunctionwith the MDMA, which keeps track of missed deadlines.
• The DeadlineTap aspect keeps track of total missed deadlines whenCOMET has a feedback configuration, i.e., MRFC, STRC or RMC.
101
• The ExecutionMonitor aspect keeps track of execution times fortransactions. To measure execution times correctly, only one singletransaction at a time can be present in the system.
8.2 Execution Time Measurements
The goal of measuring transaction execution times is to evaluate perform-ance of COMETv3.0 in comparison to COMETv1.5. Several executiontime performance experiments where run on COMET v3.0, configured withthe MRFC aspect package. For each experiment a series of 1000 transac-tions are submitted and the execution times measured. The experimentsare performed both with and without CCF. Table 8.1 presents the resultsof these experiments. The first row displays the average actual executiontime, AEi, for one transaction. The second and third row display the lowerbound (LB) respectively upper bound (UB) of a 95% confidence intervalfor the execution times of all the transactions. Execution times in COMETv3.0 are very stable and no overhead in the execution time can be seen whenusing CCF. Compared to previous measurements done in COMET v1.5 [5]transactions run 6 times faster in COMET v3.0 compared to COMET v1.5.
SELECT UPDATE SELECT UPDATE(no CCF) (no CCF) (with CCF) (with CCF)
AEi [µs] 39773 59117 39669 59054LB [µs] 39604 58899 39373 58847UB [µs] 39943 59336 39964 59262
Table 8.1: Execution times for transactions running in COMET configuredwith HP2PL and MRFC
Dynamic Reconfiguration Execution Times
The goal of this experiment is to evaluate the CCF and mechanism for dy-namic reconfiguration by measuring reconfiguration execution times and
8.2. Execution Time Measurements
comparing them to transaction execution times. Two separate experi-ments are performed to measure the overhead of dynamically reconfiguringCOMET during run-time. Both experiments are run with submitting UP-DATE transactions to COMET. The first experiment allowed only one singletransaction at a time to be present in COMET, thus guaranteeing that nocomponent internal states need to be exported and imported during thereconfiguration. The results of the experiment are presented in table 8.2.It can be observed that the execution time of swapping a component is sub-stantially lower than the execution time for a transaction (see tables 8.1and 8.2). This can be explained by the way in which the CCF is imple-mented. Swapping a component is implemented by re-pointing interfacepointers managed by the CCF (see section 6.4.1). The execution timesconfirm that requirement R7 (see table 6.1) is fulfilled. From table 8.2 onecan also conclude that, when swapping multiple components, the swappingmechanism requires approximately an additional 3 ms for each additionalcomponent.
Comp. Task Time [µs]MMC Component exchange 7959TMC Component exchange 7803SMC Component exchange 8034MMC and TMC Component exchange 10875
Table 8.2: Execution times of swapping components during dynamic re-configuration of COMET with single transactions running
The second experiment performed during dynamic reconfiguration ofCOMET is set up in the same way as the first experiment, except theload on the database is increased to 300%, thus guaranteeing that 4 con-current transactions where running in the system at all times and thatthe SMC components ready queue of transactions needed to be exportedand imported during the swap of the SMC. Execution times of the swap-ping mechanism are measured both for the MMC component, which hasno internal state, and the SMC, which does. The results are presentedin table 8.3. Before swapping a component, the CCF monitors all active
103
transactions in the system and lets them terminate (see section 6.4.4). Thetime needed for this task is presented in the Empty active queue row of eachcomponent and corresponds to the execution time of an UPDATE transaction.The second task performed by the CCF is the actual exchange of compon-ents, i.e., re-pointing the component interface pointers. When swappingthe SMC, the time to exchange components is slightly longer compared tothe corresponding time for when one single transaction is in the system(see table 8.2). The additional time needed can be explained by the timeit takes to export the ready queue from the current version of the SMCand import it into the new version of the SMC. When the swap commandis issued, the SMC ready queue is filled with 18 transactions, i.e., it takesapproximately 100 ms per transaction to export and import an entry in theSMC. The execution times also confirm that requirement R8 (see table 6.1)is not fulfilled since no transactions can execute during the reconfiguration.
Comp. Task Time [µs]MMC Empty active queue 57663
Component exchange 8037Total swap time 65700
SMC Empty active queue 64438Component exchange 9754Total swap time 74192
Table 8.3: Execution times of swapping components during dynamic re-configuration of COMET with a 300% load
8.3 Feedback Control Performance
This section examines the performance of regular feedback control, i.e., theMRFC. The goal of the experiments performed is to evaluate the additionof a feedback control loop to COMET. In section 8.3.1 tuning experimentsfor calculation of GM and KPM are performed. A load experiment, in sec-
8.3. Feedback Control Performance
tion 8.3.2, validates the steady-state performance of the feedback configur-ations, and an experiment in section 8.3.3 examines the transient behavior.For all experiment runs, only SELECT transactions are used. Due to OS lim-itations, regarding time granularity of 10 ms for sleep statements [27], theaverage inter-arrival time, AI, of a transaction could not be properly setto generate different loads in the database. For this reason execution timesof transactions are extended by a factor 10, i.e., AEi = 400ms, making itpossible to generate and apply the desired loads on COMET.
8.3.1 Tuning Experiment
The purpose of the tuning experiment is to calculate GM and, thus, KPM .The values of GM and KPM obtained in this experiment are also used asthe initial values when running COMET with the STRC adaptive feedbackcontrol configuration (see section 8.5). The experimental setup is as follows:
• CCF is used.
• AEi = 400ms.
• Change load.
The outcome of the experiment, including 95% confidence intervals, can beseen in figure 8.1. The deadline miss ratio for each load corresponds to anaverage of five runs, measured from when steady-state has been reached.The deadline miss ratio stays equal to zero when the load is less than 100%.When the load is increased beyond 100% deadline miss ratio increases rap-idly due to the domino effect caused by the EDF scheduler (see section 2.1),and increases steadily with increasing load. In figure 8.1, the maximum de-rivative is 7.127, occurring when the load increases from 100% to 111%.Therefore, the slope, GM , is equal to 7.127 (see section 2.9.1). The execu-tion time factor, Ga, is initialized to the ratio between the longest executiontime and the mean execution time for a SELECT transaction (obtained fromexperiment in table 8.1), thus Ga = 1.1. KPM is calculated using equation(2.9),
KPM =1− p0
GaGM=
0.751.1 · 7.127
= 0.101.
105
0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.50
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Utilization
Dea
dlin
e M
iss
Rat
io
Figure 8.1: The average deadline miss ratio as a function of load for theopen-loop system
8.3. Feedback Control Performance
8.3.2 Load Experiment
The goal of the load experiment is to evaluate the addition of a feedbackcontrol loop to COMET. The experimental setup is as follows:
• CCF and MRFC are used.
• MS = 0.1.
• AEi = 400ms.
• KPM = 0.1.
• T = 10s.
• Change load.
Figure 8.2 shows the outcome of the experiment, including 95% confidenceintervals. The average deadline miss ratio remains at the deadline missratio reference, MS = 10%, when the load exceeds 100%. The outcome ofthe experiment is thus as expected, confirming the MRFC functionality.
8.3.3 Transient Performance Experiment
The performance experiment is performed to examine the transient beha-vior of COMET running with MRFC. The experimental setup is as follows:
• CCF and MRFC are used.
• MS = 0.1.
• Apply load 125%.
• AEi = 400ms.
• KPM = 0.1.
• T = 10s.
107
0.7 0.8 0.9 1 1.1 1.2 1.3 1.40
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Utilization
Dea
dlin
e M
iss
Rat
io
Figure 8.2: The average deadline miss ratio as a function of load for theclosed-loop system
8.3. Feedback Control Performance
0 10 20 30 40 50 60 70 80 900
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Sample
Dea
dlin
e M
iss
Rat
io
Figure 8.3: Transient behavior of COMET with MRFC applied
109
Figure 8.3 displays the result for a single experiment run. Although thedeadline miss ratio average of the run is approximately at the deadlinemiss ratio reference, MS , the transient behavior is not satisfactory, sincethe variations in deadline miss ratio are too large. The reason for thisare the bursts of transactions missing their deadline caused by the dominoeffect of the EDF scheduler [7]. A more suitable sample period must bechosen, by running experiments with different sample periods, to reduce theeffect of these bursts in deadline miss ratio [2]. The results of the sampleperiod experiment is discussed in section 8.4 below.
8.4 Sampling Periods
To be able to decide a suitable sampling period, T , for the feedback loop,a series of experiment runs with different sampling periods are performed.The experimental setup is as follows:
• CCF and MRFC are used.
• Apply load 111%.
• MS = 0.1.
• AEi = 400ms.
• KPM = 0.1.
• Change sampling period T .
Figure 8.4 shows the results of four runs with different sampling periodschosen. The experiment runs are also compared by calculating the linearand the quadratic difference in deadline miss ratio and the reference foreach experiment run (see table 8.4). The linear difference can be writtenas
Ja =n∑k=0
|MS −m(k)| (8.1)
8.4. Sampling Periods
0 10 20 30 400
0.2
0.4
0.6
0.8
1
Sample (T=60s)
Dea
dlin
e M
iss
Rat
io
0 10 20 30 400
0.2
0.4
0.6
0.8
1
Sample (T=20s)
Dea
dlin
e M
iss
Rat
io
0 20 40 60 800
0.2
0.4
0.6
0.8
1
Sample (T=10s)
Dea
dlin
e M
iss
Rat
io
0 100 200 3000
0.2
0.4
0.6
0.8
1
Sample (T=2s)
Dea
dlin
e M
iss
Rat
io
Figure 8.4: Transient behavior of COMET with MRFC applied using dif-ferent sampling periods
111
where k is the sampling instant, and the quadratic difference can be writtenas
Js =n∑k=0
(MS −m(k))2 (8.2)
respectively. From figure 8.4 and table 8.4 it is obvious that increasingthe sampling period leads to better transient behavior of the system. In-creasing the sampling period, though, also increases the time of runningperformance experiments on dynamic reconfiguration and adaptive feed-back control (see section 8.6). For this reason a sampling period T = 60sis considered sufficient and is used for the remainder of the performanceevaluation experiments.
Sampling period [s] #OfTerminatedTrans Js Ja
2 20 0.0582 0.15910 100 0.0277 0.12520 200 0.0092 0.08160 600 0.0045 0.055
Table 8.4: The linear and quadratic difference in deadline miss ratio forthe closed-loop system using different sampling periods1
To further investigate the transient performance and what causes thevariance in deadline miss ratio the same experiment as above is run, butfor the open-loop system. The results from the experiment are shown intable 8.5. The linear and the quadratic difference in deadline miss ratioresults correspond rather well to the results in table 8.4. Thus, we drawthe conclusion that the variance in deadline miss ratio is not caused by thecontroller, but instead by the EDF scheduler.
8.5 Self Tuning Regulator
The goal of the system identification experiment, of the self tuning regu-lator, is to examine how well the STRA’s estimation of Ga conforms to the
8.5. Self Tuning Regulator
Sampling period [s] #OfTerminatedTrans Js Ja
2 20 0.0522 0.14210 100 0.0266 0.12620 200 0.0095 0.08360 600 0.0043 0.052
Table 8.5: The linear and quadratic difference in deadline miss ratio forthe open-loop system using different sampling periods1
actual value, and thus, shows how well STRC adapts to system changes,e.g., changes in transaction execution time or system reconfiguration. Fourexperiments are performed, where:
1. Ga changes from 1.1 to 2.2
2. Ga changes from 2.2 to 1.1
3. Ga changes from 1.1 to 0.55
4. Ga changes from 0.55 to 1.1
An increase in Ga by a factor two corresponds to an increase in executiontime by a factor two, and vice versa. The experimental setup is as follows:
• CCF and STRC are used.
• Apply load 111% in experiments 1 and 2.
• Apply load 250% in experiments 3 and 4.
• MS = 0.1.
• T = 60s.
• AEi = 400ms.
• KPM = 0.1.
113
To ensure that enough transactions are submitted to COMET to guaranteethat some transaction miss their deadlines, also when execution times arechanged, different loads are used in the four experiments. Changes inGa areapplied at the 50th sampling instant. The results can be seen in figure 8.5.As can be seen in the figure, the estimation Ga will approach the actual Ga,shown as a dotted line in the figure, in all four cases, thus, adjusting KPM
to the change in transaction execution times. Noticable also is that sinceonly deadline miss ratio is measured, the settling time is longer when Gais decreased, since the controller can not detect how heavily under-utilizedthe system is.
0 50 100 150 200 2500
0.5
1
1.5
2
Sample
Est
imat
ed G
a
0 50 100 150 200 2500
1
2
3
4
Sample
Est
imat
ed G
a
0 50 100 150 200 2500
1
2
3
4
Sample
Est
imat
ed G
a
0 50 100 150 200 2500
0.5
1
1.5
2
Sample
Est
imat
ed G
a
Figure 8.5: Performance of STRA Ga estimation
8.6. Dynamic Reconfiguration
8.6 Dynamic Reconfiguration
The goals of the dynamic reconfiguration experiments are to evaluate theaddition of an adaptive feedback control loop to COMET in comparison toboth an open-loop system and a regular feedback control loop. An addi-tional goal of the experiments is to evaluate the impact dynamic reconfig-uration of COMET has on deadline miss ratio. Two separate experimentsare performed. In all the experiments performed the TMC is swapped. Theinitially used TMC is denoted TMCv1. In the first experiment the new ver-sion of TMC, namely TMCv2, introduces a delay, extending the executiontime of a transaction by 100% (see section 8.6.1). In the second experimentthe new version of TMC, namely TMCv3, removes a delay, reducing theexecution time of a transaction by 50% (see section 8.6.2). The increaseand decrease in execution times are chosen to change Ga with a factor 2,i.e., a change in execution time which is realistic and also sufficient to seedifferences in transient performance between feedback control and adaptivefeedback control.
8.6.1 Increasing Transaction Execution Time
This experiment is performed with the open-loop system and both theMRFC and STRC configurations. The experimental setup is as follows:
• CCF is used.
• MS = 0.1.
• Apply load 125%.
• T = 60s.
• AEi = 400ms when TMCv1 is used.
• AEi = 800ms when TMCv2 is used.
• KPM = 0.1.
At the 60th sample TMCv1 is swapped, introducing a delay and, thus, ex-tending the execution time to AEi = 800ms in TMCv2. The increase
115
in execution time is implemented by adding a sleep statement in theRTMC_Op_getResult operation. The results of the transient behavior ofa single experiment run can be seen in figures 8.6, 8.7 and 8.8 for open-loop, MRFC and STRC respectively. The linear and quadratic difference,calculated when deadline miss ratio has reached a steady-state, using equa-tions (8.1) and (8.2), can be seen in table 8.6 for the experiments run withthe MRFC and STRC configurations.
0 50 100 150 2000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Sample
Dea
dlin
e M
iss
Rat
io
Figure 8.6: Deadline miss ratio when delays are introduced in the open-loopsystem
Both the MRFC and STRC configurations, as well as the open-loop sys-tem, suffer from a leap in deadline miss ratio when the delay in executiontime is introduced around the 60th sampling instant and the system be-comes over-utilized. Since the open-loop system can not adjust to changes
8.6. Dynamic Reconfiguration
0 50 100 150 2000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Sample
Dea
dlin
e M
iss
Rat
io
Figure 8.7: Deadline miss ratio when delays are introduced and MRFC isapplied
Configuration Js Ja
MRFC 0.00642 0.0591STRC 0.00627 0.0587
Table 8.6: The linear and quadratic difference in deadline miss ratio whendelays are introduced
117
0 50 100 150 2000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Sample
Dea
dlin
e M
iss
Rat
io
Figure 8.8: Deadline miss ratio when delays are introduced and STRC isapplied
8.6. Dynamic Reconfiguration
in execution time the system continues to be over-utilized and deadlinemiss ratio remains at approximately 98%. The STRC and MRFC config-urations, though, adjust to the change in execution time and deadline missratio drops to the miss ratio reference value. The STRC configuration,though, has longer settling time, Ts = 1200s, than MRFC, Ts = 900s,to reach the miss ratio reference. When the system gets over-utilized Gawill start to increase according to (2.10). A higher Ga will lower KPM
according to (2.9), i.e., the system will react slower to change in deadlinemiss ratio. The slower system will therefore need a longer period of time todecrease deadline miss ratio but, when the reference level is reached, a lessoscillating transient performance should be obtained compared to regularfeedback control. Except for differences in settling time, Ts, a clear differ-ence in transient behavior can not be seen either in figures 8.7 and 8.8 orin table 8.6. In section 8.7 we explain why this is the case.
8.6.2 Decreasing Transaction Execution Time
This experiment is performed with the open-loop system and both theMRFC and STRC configurations. The experimental setup is as follows:
• CCF is used.
• Apply load 250%.
• MS = 0.1.
• T = 30s.
• AEi = 400ms when TMCv1 is used.
• AEi = 200ms when TMCv3 is used.
• KPM = 0.1.
The reason for choosing a shorter execution time, than in the previous ex-periment, is due to the fact that the UNIX station running the experimentotherwise ran out of memory. At the 120th sample TMCv1 is swapped,removing a delay and, thus, decreasing the transaction execution time toAEi = 200ms in TMCv3. The decrease in execution time is implemented
119
by removing a sleep statement in the RTMC_Op_getResult operation. Theresults of the transient behavior of a single experiment run can be seenin figures 8.9, 8.10 and 8.11 for open-loop, MRFC and STRC respectively.The linear and quadratic difference, calculated when deadline miss ratiohas reached a steady-state, using equations (8.1) and (8.2), can be seen intable 8.6 for the experiments run with the MRFC and STRC configurations.
0 50 100 150 200 250 300 350 4000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Sample
Dea
dlin
e M
iss
Rat
io
Figure 8.9: Deadline miss ratio when delays are removed in the open-loopsystem
Both the MRFC and STRC configurations, as well as the open-loopsystem, suffer from under-utilization when the delay in execution time isremoved around the 120th sampling instant, thus dropping the deadlinemiss ratio to zero. Since the open-loop system can not adjust to changes in
8.6. Dynamic Reconfiguration
0 50 100 150 200 250 300 350 4000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Sample
Dea
dlin
e M
iss
Rat
io
Figure 8.10: Deadline miss ratio when delays are removed and MRFC isapplied
Configuration Js Ja
MRFC 0.00737 0.0667STRC 0.00752 0.0693
Table 8.7: The linear and quadratic difference in deadline miss ratio whendelays are introduced
121
0 50 100 150 200 250 300 350 4000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Sample
Dea
dlin
e M
iss
Rat
io
Figure 8.11: Deadline miss ratio when delays are removed and STRC isapplied
8.7. Changing Controller Parameter Value
execution time the system continues to be under-utilized and deadline missratio remains at 0%. The STRC and MRFC configurations, though, adjustto the change in execution time and deadline miss ratio drops to the missratio reference value. The STRC configuration has shorter settling time,Ts = 1600s, than MRFC, Ts = 2400s, to reach the miss ratio reference.When the system gets under-utilized, Ga will start to decrease accordingto equation (2.10). A lower Ga will increase KPM according to equation(2.9), i.e., the system will react faster to change in deadline miss ratio. Thefaster system will therefore need a shorter period of time to increase util-ization and, thus, deadline miss ratio. When the reference level is reacheda less oscillating transient performance should also be obtained comparedto regular feedback control. Except for differences in settling time, Ts, aclear difference in transient behavior can not be seen either in figures 8.10and 8.11 or in table 8.7. In section 8.7 we explain why this is the case.
Another conclusion which can be drawn from this experiment is thatno noticeable increase in deadline miss ratio can be seen in the samplesdirectly after the reconfiguration has occurred for the open-loop system infigure 8.9. Since the execution time of the swapping mechanism is onlyslightly longer than the execution time for a transaction (see tables 8.3and 8.1), the delay introduced by dynamically reconfiguring the systemdoes not considerably affect deadline miss ratio. The reason for this is thattransactions only are postponed for the duration of the reconfiguration andthe transaction deadlines are in average Di = (10·AEi ms), i.e., the relativetransaction deadlines will be slightly shortened.
8.7 Changing Controller Parameter Value
The goal of this experiment, using feedback control, is to evaluate thesteady-state transient behavior of deadline miss ratio when the controllerparameter is changed from its calculated value of KPM = 0.1. Neitherextending or decreasing the execution time with a factor 2 showed anynoticeable benefit of using adaptive feedback control compared to regularfeedback control, although the self tuning regulator proved that it adap-ted the controller parameter to changes in execution time (see section 8.5).Therefore an experiment is conducted to examine the behavior of the regu-
123
lar feedback control with different controller parameters. The experimentalsetup is as follows:
• MRFC and CCF are used.
• Apply load 125%.
• MS = 0.1.
• T = 60s.
• AEi = 400ms.
• Change KPM value.
Four different controller parameters are used and compared with the ref-erence calculated controller parameter, KPM = 0.1. The linear and quad-ratic difference for the different controller parameter values, calculated fromequations (8.2) and (8.1), can be seen in table 8.8. Remember that increas-ing KPM by a factor 2 corresponds to a decrease in Ga with a factor 2, i.e.,a decrease in transaction execution time by a factor 2.
KPM Js Ja
0.01 0.0091 0.07760.05 0.0042 0.05040.10 0.0040 0.04850.20 0.0041 0.05341.00 0.0126 0.0889
Table 8.8: The linear and quadratic difference in deadline miss ratio usingMRFC and varying controller parameter
Running regular feedback control with a controller parameter valuetwice or half the size of the reference calculated controller parameter per-forms almost as well as when using KPM = 0.1. Therefore when STRCadapts its controller parameter to changes in execution time, no noticeableincreased transient performance can be seen. If the controller parameters
8.8. Conclusions
are increased or decreased by a factor 10, though, the transient behaviorof the regular feedback control is decreased. This would correspond to anincrease or decrease in execution times by a factor 10, which is not likelyin a real-time system.
8.8 Conclusions
Execution times in COMET v3.0 have greatly improved in comparison toCOMET v1.5, due to the merging and improvements implemented (see sec-tion 5). Still execution times of transactions are rather long for a real-timedatabase, and further execution time analysis would be beneficial. Theexecution time measurements when the CCF is used show that the com-ponent framework is very effective in handling communication between thecomponents when components are not being swapped. At the same time,a more effective swapping mechanism than stopping all transaction execu-tion during dynamic reconfiguration would be beneficial to lower executiontimes of the swapping mechanism.
Adding a regular feedback control loop to COMET v3.0 significantlyimproves deadline miss ratio, keeping it at the deadline miss ratio refer-ence. The addition of an adaptive feedback loop, does not show a notice-able increased performance in deadline miss ratio, although the self tuningregulator is proved to recalculate the controller parameter according tochanges in execution time (see section 8.5). Since increasing or decreasingthe execution time with a factor 2 (as discussed in section 8.7) shows nonoticeable increase in transient behavior, except for settling time, for theadaptive self tuning regulator, it is not feasible to run additional perform-ance experiments using RMC. Larger increases and decreases in executiontime could show the benefits of using an adaptive controller, but variationsof such magnitude are not likely in a real-time system.
125
Chapter 9
Summary
This chapter provides conclusions drawn during this thesis project andidentifies areas for future work.
9.1 Conclusions
This section contains conclusions drawn during this thesis project, and arerelated to understanding COMET, improving stability and performance,aspect maintainability, dynamic aspect weaving and adaptive feedback con-trol.
Understanding COMET
The COMET system, with all its configurations, is a rather large system,making it both difficult and time consuming for a new COMET projectmember to understand all its functionality and features. By the contri-bution of a complete reference documentation of COMET v3.0 and itsconfigurations, COMET v3.0 is now easier to overview. The knowledgethreshold for a future COMET developer has therefore been greatly re-duced. The provided reference documentation consists of a user manual,a function dependency document, and a more distinct separation of inter-faces, operations and mechanisms, using the naming and coding standard.
9.1. Conclusions
COMET Stability and Performance
Several improvements have been introduced into COMET v3.0 to generatea more stable system. Memory leaks have been fixed, platform specificbugs on UNIX have been fixed, initial error handling framework has beendeveloped, and changes have been made to guarantee that uninitializedmemory is not read. The COMET system is now a more stable system,and thus more suitable for further component and aspect functionality im-plementation. The performance of COMET v3.0 has been greatly improvedin comparison to COMET v1.5. Execution times when running COMETwith QoS have been reduced with a factor 6. Still, there exists performanceissues that could be addressed to further improve performance (describedin section 9.2). The reduction of execution times also gives the possibilityto re-implement the QMF configuration to COMET v3.0, since the failureof benefiting from that configuration in COMET v1.5 depended mainly onhigh execution times [5].
Aspect Maintainability
An interesting issue, when merging the COMET v1.5 and COMET v2.0versions into COMET v3.0, is to which degree current aspects for con-currency control and QoS management had to be adjusted to make themwork with COMET v3.0. Our conclusions on this issue is that aspects arevery sensitive to changes in component code that effects aspect join points.Changes in function names and arguments lead to advice code not beingwoven in by the AspectC++ weaver. Since the AspectC++ weaver doesnot warn if no functions match the specified join points in the componentcode, this could easily lead to aspects not functioning correctly. Aspectsgenerally do not require many changes beside changes to join point functionnames and parameters. Of course, if new functions are added or functionsare removed from the components, more in depth alterations of the aspectsare needed.
Debugging COMET
Debugging in COMET is problematic. Error handling in COMET v3.0 isstill inferior. Several checks, e.g. checking that indexes of arrays are valid,
127
have been introduced, but still errors in COMET often lead to hard-to-find segmentation faults. Since very much time is spent locating errors,much time could be saved by implementing a more in depth error handlingmechanism and would be very beneficial for future COMET development.By generating debug printouts, stating where an error has occurred anddescribing its nature, implementation time would be significantly decreased.
Dynamic Aspect Weaving
Since aspects cross-cut many components, and their code is woven into thecomponents during the AspectC++ precompilation, all components need tobe made swappable if aspects also are to be made swappable. Currently allcomponents except the UIC and IMC components can be swapped duringrun-time. By implementing export and import functions for the currenttransactions in the UIC and the index structure containing addresses totuples and metadata in the IMC, in a similar fashion as the SMC, thesecomponents could also be made swappable. By making it possible to swapall components, it is possible, by precompiling a different aspect into allcomponents, e.g., a different concurrency aspect, and swapping all COMETcomponents, to make the aspects swappable. One can say that dynamicaspect weaving has been made possible.
Designing Aspects For Component Swapping
Depending on if an aspect cross-cuts many components or, as in the QoSaspects case, only cross-cut one component a technique for saving the as-pects internal state should be chosen. When an aspect cross-cuts manycomponents which need to maintain the same aspect internal data, e.g.,HP2PL, generating a separate object file for these parts of the aspect isthe preferable solution. If an aspect only cross-cuts one component, e.g.,the QoS aspects, the aspect should also contain advice to save their in-ternal states before a component is swapped. The aspect should also haveadvice to restore its internal state when the new component version hasbeen swapped in. If this is the case the current COMET structs should,to as far extent as possible, be used for export and import of the internalstate, i.e., the DBTrans struct should be used to store transaction specific
9.2. Future Work
data and the UIC_SystemParameters struct should be used to store systemspecific data.
AspectC++ Weaver
The AspectC++ compiler weaves a lot of code into the original code files,thus creating large output files. The weaver seems to be rather inefficientin the way it handles file header inclusions, which could be a problem ifthe weaved files are compiled to be used in a system with scarce memoryresources, e.g., an embedded system. Another problem is that only C++code can be generated. The compiled system will, thus, not be portable toa system only able to execute C code executables, e.g., to a micro controllerin an engine electronic control unit (EECU). Solutions to these issues areto either find an aspect weaver generating C code, or to develop a simpleweaver.
Adaptive Feedback Control
Adding a regular feedback control loop to COMET v3.0 significantly im-proves deadline miss ratio, keeping it at the deadline miss ratio reference.The addition of an adaptive feedback loop does not show a noticeable in-creased performance in deadline miss ratio, although the self tuning regu-lator is proved to recalculate the controller parameter according to changesin execution time. Since increasing or decreasing the execution time witha factor 2 shows no increase in transient behavior, except for settling time,for the adaptive self tuning regulator, it makes little sense to run additionalperformance tests using RMC. Larger increases and decreases in executiontime could show the benefits of using an adaptive controller, but variationsof such magnitude are not likely to occur in a real-time system.
9.2 Future Work
Error handling in COMET is inferior and should be improved. For now,debugging is often inefficient, with hard to find errors and little guidancefor the developer. Improvements in index handling can also be done. Whenloading a relation, an index search is performed for each key in the relation.
129
Since relations are loaded upon every database operation, this implementa-tion degrades performance heavily. Also some other performance issues stillexist and should be optimized, e.g., there are a number of inefficient sequen-tial searches which search through complete arrays even though they couldbe empty or contain only a few elements. The implementation of metadatashould be changed into, e.g., structs, which are easier, more efficient, andmore aspect friendly.
The on-demand updating of data, QMF, earlier developed as a COMETconfiguration, has not been changed or tested with COMET v3.0. Since ex-ecution times are considerably lower than in COMET v1.5, reimplementingQMF and also conforming it to extended RTCOM, can prove to be bene-ficial.
The mechanism for dynamic reconfiguration of COMET can be mademore efficient and flexible, e.g., dynamic extensibility can be implemented,state sensitivity has to be preserved for the UIC and the IMC (both defaultand B-Link), and side-effects which can be minimized. Further, the ODCaspect does not conform with extended RTCOM, and Guard-Link mustbe in its own shared object to make the components swappable. Propertesting of ODC and Guard-Link should also be performed to ensure validfunctionality with COMET v3.0, e.g., ODC can only manage one queryper transaction.
The COMET project has run for many years, and a lot of interestingresults and conclusions have been found. To further evaluate the COMETdatabase it should be ported to a real-time embedded environment, suchas an EECU.
In this thesis, only a deadline miss ratio control loop is used. Systemperformance would be greatly improved if the deadline miss ratio controlloop was integrated with a utilization control loop (as in FC-UM), whichwould solve the problems of handling both overloaded and underutilizedsystems. If only monitoring deadline miss ratio, saturation is likely tooccur when having an underutilized system. Another drawback, when onlymonitoring deadline miss ratio, occurs in the adaptive case after a deadlinemiss ratio burst, due to, e.g., a dynamic reconfiguration. The deadline missratio will then decrease slower than regular feedback control, due to a lowercontrol variable. Using a utilization control loop would, in the describedscenario, result in a much faster decrease in deadline miss ratio [35].
9.2. Future Work
To investigate the field of adaptive feedback control further, more ad-aptive algorithms and techniques can be evaluated in terms of control per-formance, computational complexity, and memory consumption. At first,the implementation of the ARMA should be evaluated, since this is notdone in this thesis. Feed-forward structures can be developed to forward aprediction of the system state, e.g., at dynamic reconfiguration of COMET,to improve the control performance. The transient behavior of deadlinemiss ratio depends heavily on sampling period, due to the domino effectof the EDF scheduler. Further testing of the adaptive algorithms usinglonger sampling periods should be investigated. To achieve this a more finegranular mechanism for submitting transactions to COMET must be usedto be able to eliminate the simulated longer execution times and still beable to vary the load in a satisfactory way. The authors found, too late,that there exist possibilities to change the frequency of the clock in Solarisand achieve this [27].
131
Appendix A
Abbreviations
AC Admission ControlACC Admission Control ConfigurationACCORD AspeCtual COmponent-based Real-time system De-
velopmentAFC-M-STR Adaptive Feedback Control-Miss ratio-Self Tuning
RegulatorAFC-M-RM Adaptive Feedback Control-Miss ratio-Regression
ModelAOSD Aspect-Oriented Software DevelopmentAPI Application Program InterfaceARMA Adaptive Regression Model AspectBMC Buffer Manager ComponentBOT Beginning Of TransactionCCF COMET Component FrameworkCDSB Component-Based Software DevelopmentCOMET COMponent based Embedded real-Time database
systemEECU Engine Electronic Control UnitEDF Earliest Deadline First
EOT End Of TransactionFCC Feedback Control ComponentFCCA Feedback Control Composition AspectFC-M Feedback Control-Miss ratioFC-U Feedback Control-UtilizationFC-UM Feedback Control-Utilization and Miss ratioGUARD Gatekeeping Using Adaptive eaRliest DeadlineHP2PL High Priority 2-Phase LockingIMC Indexing Manager ComponentLMC Locking Manager ComponentMDMA Missed Deadline Monitor AspectMMC Memory Management ComponentMRFC Miss Ratio Feedback ControlODC Optimistic Divergence ControlQAC QoS Actuator ComponentQACA QoS Actuator Component AspectQMF QoS sensitive approach for Miss ratio and Freshness
guaranteesQoS Quality of ServiceRLS Recursive Least SquaresRMC Regression Modele ConfigurationRMS Rate Monotonic SchedulingRTCOM Real-Time COMponent modelRTDB Real-Time DataBaseRTS Real-Time SystemSMC Scheduler Manager ComponentSQL Structured Query LanguageSTR Self-Tuning RegulatorSTRA Self-Tuning Regulator AspectSTRC Self-Tuning Regulator ConfigurationTMC Transaction Manager ComponentTRTA Transactional Real-Time AspectUIC User Interface ComponentUMCA Utilization from Missed deadline Control AspectWCET Worst-Case Execution Time
133
Appendix B
Terminology
Term DescriptionAbortedtransaction
A transaction stops its execution abruptly,thus not finalizing all its operations.
Aspect pack-age
A set of aspects and components, which com-bined perform a specific functionality.
COMET con-figuration
An executable version of COMET with a spe-cified set of components and aspects applied.
Completedtransaction
A transaction that has executed all its opera-tions.
Componentswapping
Exchanging one component for another, e.g.,a new version of the same component.
Controllerparameter
Parameter for specifying a controller behavior.
Controllertuning vari-able
Variable for adapting controller behavior toworkload variations.
Term DescriptionControlledvariable
The performance metrics controlled by thescheduler.
Dynamic re-configuration
Reconfiguration of a component-based real-time system during run-time by means of ex-changing components or aspects.
Executiontime
The time it takes to perform a number of op-erations, e.g., by a transaction.
Manipulatedvariable
System attribute that can be dynamicallychanged by the scheduler to affect the valuesof the controlled variables.
Performancereference
The desired system performance in terms ofthe controlled variables.
Terminatedtransaction
A transaction leaves the system either becauseall of its operations have executed, or becauseits deadline has passed and it is not allowedto start execution.
Transaction A set of read and/or write operations to thedatabase.
135
Appendix C
Variables
Variable Description PageAEi actual execution time of transaction τi 10AI average inter-arrival time for a series of transac-
tions10
AUi actual CPU utilization of transaction τi 10AV Ii absolute validity interval of data object di 9dM (k) change in total estimated utilization for miss ratio
controller at the kth sampling instant20
dU (k) change in total estimated utilization for utiliza-tion controller at the kth sampling instant
19
Di relative deadline of transaction τi 10EEi estimated execution time of transaction τi 10ε(t) prediction error in a regression model at time t 24EUi estimated CPU utilization of transaction τi 10G(z) transfer function for open-loop system 91Gc(z) transfer function for closed-loop system 92Ga(k) execution time factor 22GM slope of linearzation 22Ja linear difference 109Js quadratic difference 111KPM control parameter for miss ratio controller 20
Variable Description PageKPU control parameter for utilization controller 19λ forgetting factor used in RLS to decide relevance
of old sample values25
Mo miss ratio overshoot 18m(k) miss ratio at the kth sampling instant 17m(k) estimation of miss ratio at the kth sampling in-
stant90
Mmax maximum value of miss ratio 19MS miss ratio reference level 18Pi invocation period of transaction τi 10ϕ(k) regression vector in the kth sampling instant 24teu(k) total estimated utilization at the kth sampling in-
stant19
T sample period 18Ts settling time 18θ(k) parameter vector in the kth sampling instant 24TSi time stamp of the latest di access operation 9u(k) total actual (CPU) utilization at the kth sampling
instant18
Umax maximum value of CPU utilization 19Uo CPU utilization overshoot 19US CPU utilization reference level 18V (θ, t) loss function for regression model 24
137
Appendix D
Test Runs
This appendix contains test run printouts when running COMET. Ap-pendix D.1 contains a printout of a set of transactions submitted to COMET.Appendix D.2 contains a debug printout when testing a COMET configur-ation with MRFC. For information on debug printout see section 5.6.
D.1 Test Runs in COMET v3.0
In lines 1-5 a table is created and three tuples are inserted. When running aSELECT transaction on line 6, the expected result can be seen in lines 7-9. Inline 10 tuples containing an address equal to VasaStr are updated by settingthe salary attribute to 25000. When running the SELECT transaction online 11, only chosing tuples where the salary attribute is equal to 15000or the city attribute is equal to Sthlm, the correct results are returned inlines 12-13. Tuples where the city attribute is equal to Link and where thesalary attribute is larger than 22000 are deleted in line 14. By selecting alltuples in line 15, the results in line 16 confirm that the tuples were deleted.
1. CREATE TABLE emp (nr# float, salary int, city char(8),2. address string),PRIMARY KEY(nr#)3. INSERT INTO emp VALUES (2.2, 10000, Sthlm, Vasastr)4. INSERT INTO emp VALUES (3.3, 15000, Link, Vallav)
D.2. Test Runs with QoS Management Aspects
5. INSERT INTO emp VALUES (4.4, 20000, Norrk, Kungsg)6. SELECT * FROM emp
****************************Result************************7. Rownumber: 0 2.200000 10000 STHLM VASASTR8. Rownumber: 1 3.300000 15000 LINK VALLAV9. Rownumber: 2 4.400000 20000 NORRK KUNGSG
****************************Result************************10. UPDATE emp set salary=25000 WHERE emp.address=Vasastr11. SELECT * FROM emp WHERE emp.salary=15000 OR emp.city=Sthlm
****************************Result************************12. Rownumber: 0 2.200000 25000 STHLM VASASTR13. Rownumber: 1 3.300000 15000 LINK VALLAV
****************************Result************************14. DELETE FROM emp WHERE emp.city=Link AND emp.salary>2200015. SELECT * FROM emp
****************************Result************************16 Rownumber: 0 4.400000 20000 NORRK KUNGSG
****************************Result************************
D.2 Test Runs with QoS Management As-pects
Debug printouts was used to verify QoS Management correctness. A typicaltest run can be seen below:
1. [2] DEBUG(256): ***************SAMPLE TAKEN*************2. [2] DEBUG(256): UtilizationTarget changed to: 0.9103993. [2] DEBUG(256): ***************SAMPLE TAKEN*************4. [2] DEBUG(256): UtilizationTarget changed to: 0.9105995. [2] DEBUG(256): ***************SAMPLE TAKEN*************6. [1] DEBUG(1): RUIC_Op_startTransaction()7. [1] DEBUG(256): utilTarget > totalUtil + trans->util:8. [1] DEBUG(256): 0.910599 > 0.400000 + 0.2000009. [1] DEBUG(256): RQAC admitted transaction, transID=18.10. [1] DEBUG(256): AdmittedTransactions: 1
139
11. [1] DEBUG(32): Starting thread with threadhandle 7.
12. [1] DEBUG(1): RUIC_Op_startTransaction()13. [1] DEBUG(256): utilTarget > totalUtil + trans->util:14. [1] DEBUG(256): 0.910599 > 0.600000 + 0.20000015. [1] DEBUG(256): RQAC admitted transaction, transID=19.16. [1] DEBUG(256): AdmittedTransactions: 217. [1] DEBUG(32): Starting thread with threadhandle 8.
18. [1] DEBUG(1): RUIC_Op_startTransaction()19. [1] DEBUG(256): utilTarget > totalUtil + trans->util:20. [1] DEBUG(256): 0.910599 > 0.800000 + 0.20000021. [1] DEBUG(1): RQAC rejected transaction, transID=20.
22. [1] DEBUG(1): SMC_Op_CreateNew failed
23. [7] DEBUG(1): Entering commitTransaction. TransID: 1824. [8] DEBUG(1): Entering commitTransaction. TransID: 19
25. [7] DEBUG(1): Transaction with transID 18 finished.26. [7] DEBUG(32): SMC_Op_Completed()
27. [8] DEBUG(1): Transaction with transID 19 finished.28. [8] DEBUG(256): Deadline missed, missedTransactions: 129. [8] DEBUG(32): SMC_Op_Completed()
30. [2] DEBUG(256): RSMC_GetDeadlineMissratio: 0.50000031. [2] DEBUG(256): UtilizationTarget changed to: 0.90979932. [2] DEBUG(256): ***************SAMPLE TAKEN*************33. [2] DEBUG(256): UtilizationTarget changed to: 0.90999934. [2] DEBUG(256): ***************SAMPLE TAKEN*************
In lines number 2 and 4 a sample is taken and the utilization target isrecalculated. A new submitted transaction starts execution on line 6, thusgetting intercepted by the QAC. Before the transaction is started its utiliz-ation is used in the equation at line 13 to determine if it should be allowed
D.2. Test Runs with QoS Management Aspects
to start executing. If the utilization of all transactions currently in the sys-tem and the submitted transaction’s utilization is less than the utilizationtarget, the transaction is admitted to the SMC. Line 9 announces that thesubmitted transaction is admitted. The transaction is given the the trans-action identifier number 18 and is started in a thread with identifier 7. Inlines 12-17 the procedure is repeated and another transaction is admittedto start execution. It is given the transaction identifier 19, and is startedin a thread with identifier 8. A third transaction is submitted on line 18.The transaction is rejected in lines 19-21, confirming the functionality ofthe ACC configuration.
The transactions with transaction identification number 18 and 19 arecompleted on lines 23-24. Transaction 18 finishes on line 25, and thentransaction 19 finishes on line 27. The transaction with transaction iden-tification number 19, however, misses its deadline (line 28). In lines 30-32a new sample is taken and, since the miss ratio in the previous samplewas above the miss ratio reference value, the utilization target is lowered,allowing the system to admit fewer transaction and, thus, confirming thefunctionality of the MRFC configuration.
141
Appendix E
Division of Workload
Since this is a two person project, this appendix presents the division ofworkload among the two project participants as follows. Table E.1 containsa description of all the project phases. Tasks performed by Daniel Nilssonare given in table E.2, and tasks performed by Henrik Norin in table E.3.
Phase DescriptionP1 All background studies are performed of COMET, component
composition, adaptive feedback control techniques and devel-opment tools and environments.
P2 During this phase all choices regarding COMET improve-ments, adaptive control algorithm choices and strategy for dy-namic system reconfiguration run-time should be summarizedin chapters 1, 2, 3, and 4.
P3 Implementation of the proposed COMET improvements fromP2 are performed during this phase. Merge the currentCOMET baseline with the COMET baseline changed by DagNystrom at Malardalens Hogskola.
P4 In this phase the improvements implemented in the previousphase and the COMET system is tested to guarantee a stablesystem. The outcome of this phase should be a stable and re-liable version of COMET, suitable for implementation of thechosen adaptive techniques and dynamic reconfiguration dur-ing run-time.
P5 Implementation and testing of dynamic reconfiguration ofCOMET is performed in this phase. The design and imple-mentation should be documented and later be included intochapters 5 and 6.
P6 This phase is the design phase of the adaptive QoS controlalgorithms. Deliverable from this phase should be chapter 7,including the design and implementation from P5.
P7 During this phase the implementation of the adaptive controlaccording to the design developed in the previous phase.
P8 Development of the test bench for the performance evaluationis implemented during this phase. This phase should deliver aworking adaptive QoS test suit.
P9 This phase is the performance evaluation phase. The resultsand observations of the measurements will be documented inchapter 8.
P10 In the last phase of the project the final Master Thesis is pro-duced and defended.
Table E.1: Description of project phases
143
Phase DescriptionP1 All background studies were performed of COMET, component
composition, adaptive feedback control techniques and devel-opment tools and environments.
P2 Wrote sections 2.1-2.3, 2.8, 2.9.2, and 4.3. Chapter 1 and 3jointly written.
P3 Jointly merged component versions of COMET v1.5 andCOMET v2.0. Daniel mainly merged and implemented im-provements in the UIC, IMC, FCC, and QAC components.Adapted all concurrency control and QoS aspects to COMETv3.0. Fixed DOXYGEN documentation for COMET system.Created program for generating functional dependencies docu-ment. Developed and enforced a naming and coding standardon all components and aspects.
P4 Tested QoS aspect functionality. Wrote sections 5.1-5.4, 5.6-5.7, 5.9, 5.11 and corresponding sections in the COMET UserManual. Also wrote building COMET chapter in the UserManual.
P5 Made component interface changes, debugger and aspect ad-justments to conform to extended RTCOM and run with CCF.Wrote chapter 6 except sections 6.4.1 and 6.4.4.
P6 Designed the least squares and regression model adaptive feed-back control algorithm. Wrote section 7.2.2.
P7 Implemented the ARMA aspect.P8 Developed the test bench. Made adaptions to run them using
CCF.P9 Performance evaluation of regular feedback control and STRC.
Wrote section 8.7 and 8.8. Created figures.P10 Jointly compiled all chapters into the final Master Thesis and
defended the thesis.
Table E.2: Tasks performed by Daniel Nilsson
Phase DescriptionP1 All background studies were performed of COMET, component
composition, adaptive feedback control techniques and devel-opment tools and environments.
P2 Wrote sections 2.4-2.7, 2.9.1, 4.1-4.2. Chapters 1 and 3 jointlywritten.
P3 Jointly merged component versions of COMET v1.5 andCOMET v2.0. Henrik mainly merged and implemented im-provements in the TMC, SMC, LMC, MMC. Porting COMETv2.0 to UNIX.
P4 Wrote sections 5.5, 5.8, 5.10 and tables. Debugging of COMETv2.0 ported to UNIX. Testing and debugging of HP2PL.
P5 Wrote sections 6.4.1, 6.4.4. Implemented the CCF. Implemen-ted mechanisms for ensuring component safe states.
P6 Wrote sections 7.1, 7.2.1. Designed the self tuning regulatoradaptive feedback control algorithm.
P7 Implemented the STRA aspect.P8P9 Wrote sections 8.1-8.6.P10 Jointly compiled all previous chapters and added chapter 9 into
the final Master Thesis and defended the thesis.
Table E.3: Tasks performed by Henrik Norin
145
Bibliography
[1] R.K. Abbott and H. Garcia-Molina. Scheduling real-time transactions:A performance evaluation. ACM Transactions on Database Systems,17(3), pp. 513-560, 1992.
[2] M. Amirijoo, J. Hansson, S. Gunnarsson, and S. H. Son. Enhan-cing Feedback Control Scheduling Performance by On-line Quantific-ation and Suppression of Measurement Disturbance. IEEE Real-Timeand Embedded Technology and Applications Symposium (RTAS), USA,2005.
[3] G. Andersson, U. Jorner, and A. Agren. Regressions- och tidsserieana-lys med och utan datorstod. Studentlittertur, 2nd edition, 1994.
[4] K. J. Astrom, B. Wittenmark. Adaptive Control. Addison-Wesley,1989.
[5] M. Bjork. QoS Management in Configurable Real-Time Databases.Master Thesis, LiTH-IDA-EX-04/071-SE, LiTH, 2004.
[6] J. Bosch. Design and Use of Software Architectures. ACM andAddision-Wesley, 2000.
[7] A. Burns and A. Wellings. Real-Time Systems and Programming Lan-guages. Addison-Wesley, 2nd edition, 1996.
[8] A. Gang. Software Hot-Swapping Techniques For Upgrading MissionCritical Applications On The Fly. Master Thesis, Carleton University,Canada, 2000.
BIBLIOGRAPHY
[9] N. Dulgheru. Management of QoS in Distributed MPEG Video Sys-tems. Master Thesis, LiTH-IDA-EX-04/014-SE, LiTH, 2004.
[10] S. Eriksson, I. Hedman, and G. Mwepu. Implementation of a Data-base for a Hard Real-Time Control System. Master Thesis, MalardalenUniversity, 2003.
[11] K. Erlandsson. Concurrency Control in a Configurable Component-Based Real-Time Database. Master Thesis, LiTH-IDA-EX-04/069-SE,LiTH, 2004.
[12] T. Glad and L. Ljung. Control Theory, Multivariable and NonlinearMethods. Taylor & Francis, 2000.
[13] J. Hannemann, R. Chitchyan, and A. Rashid. Analysis of Aspect-Oriented Software. In Proceedings of the European Conference onObject-Oriented programming, vol. 3013, pp. 154-164, 2004.
[14] J.R. Haritsa and S. Seshadri. Real-time index concurrency control.IEEE Transactions on Knowledge and Data Engineering, 12(3), pp.429-447, 2000.
[15] D. van Heesch. User Manual for Doxygen 1.3.8.ftp://ftp.stack.nl/pub/users/dimitri/doxygen manual-1.3.9.1.pdf.zip,Acc. 2004-10-05, 2004.
[16] A. Issoton C++ dlopen mini HOWTO.http://www.isotton.com/howtos/C++-dlopen-mini-HOWTO/C++-dlopen-mini-HOWTO.html, Acc. 2004-10-05, 2003.
[17] ITEA project. ROBOCOP Deliverable 1.5 - Revised specification offramework and models.http://www.extra.research.philips.com/euprojects/robocop/deliverables public/robocop wp1 deliverable15 18july2003.pdf, Acc.2004-09-25, 2003.
[18] C.M Krishna and Kang G. Shin. Real-Time Systems. McGraw-Hill,1997.
147
[19] L. Ljung and T. Soderstrom Theory and Practice of Recursive Identi-fication. MIT Press, 1983.
[20] C. Lu, J.A Stankovic, S.H Son, and G Tao. Feedback Control Real-Time Scheduling: Framework, Modeling and Algorithms. Real-TimeSystems Journal, vol. 23, no.1-2, pp. 85-126, 2002.
[21] D. Nilsson and H. Norin. COMET User Manual. Technical Report,LiTH, 2004.
[22] R. van Ommering. KOALA - a Component Model for ConsumerElectronics Product Software.http://www.extra.research.philips.com/SAE/koala/pub/ares2 rvo.pdf,Acc. 2004-10-25, Philips Research Eindhoven, 2003.
[23] The Open Group. The Open Group Base Specifications Issue 6,dlfcn.h - dynamic linking.http://www.opengroup.org/onlinepubs/009695399/basedefs/dlfcn.h.html,Acc. 2004-11-02, 2004.
[24] H. Ozbay. Introduction to Feedback Control Theory. CRC Press LLC,2000.
[25] K. Ramamritham. Real-time databases. International Journal of Dis-tributed and Paralell Databases, vol. 1, iss. 2, pp. 199-226, 1993.
[26] Sun Microsystems. Linker and Libraries Guide.http://docsun.cites.uiuc.edu/sun docs/C/solaris 9/SUNWdev/LLM/toc.html, Acc. 2004-11-02, 2004.
[27] Sun Microsystems. Solaris Tunable Parameters Reference Manual.http://docsun.cites.uiuc.edu/sun docs/C/solaris 9/SUNWaadm/SOLTUNEPARAMREF/p20.html, Acc. 2005-02-03, 2005.
[28] O. Spincyk, A. Gal, and W. Schroder-Preikschat. Aspect C++: Anaspect-oriented extension to C++. In Proceedings of the 40th Inter-national Conference on technology of Object-Oriented Languages andSystems, 2002.
BIBLIOGRAPHY
[29] J. A. Stankovic, T. F. Abdelzaher, K-D Kang, and S. H. Son. AQoS-Sensitive Approach for Timeliness and Freshness Guarantees inReal-Time Databases. In EuroMicro Conference on Real-Time Sys-tems, 2001.
[30] C. Szyperski. Component Software: Beyond Object-Oriented Program-ming. Addison-Wesley, 2nd edition, 2002.
[31] A. Tanenbaum. Computer Networks. Prentice Hall, 4th edition, 2003.
[32] A. Tesanovic. Towards Aspectual Component-Based Real-Time SystemDevlopement. Licentiate Thesis, LiTH, 2003.
[33] A. Tesanovic, D. Nystrom, J. Hansson, and C. Norstrom. Aspects andComponents in Real-Time System Development: Towards Reconfig-urable and Reusable Software. Journal of Embedded Computing, vol.1, 2004.
[34] A. Tesanovic, M. Amirijoo, M. Bjork, and J. Hansson. Empower-ing Configurable QoS Management in Real-Time Systems. In ACMInternational Conference on Aspect-Oriented Software Development(AOSD), 2005.
[35] L. Wei and H. Yu. Research on a Soft Real-Time Scheduling AlgorithmBased on Hybrid Adaptive Control Architecture. In Proceedings of theAmerican Control Conference, vol. 5, pp. 4022-4027, 2003.
[36] K.L. Wu, P.S. Yu, and C. Pu. Divergence control for epsilonserializab-ility. In Proceedings of 8th International Conference on Data Engin-eering, pp. 506-515, 1992.
[37] W. Zhuang. RLS Algorithm with Variable Forgetting Factor for De-cision Feedback Equalizer over Time-Variant Fading Channels. Wire-less Personal Communications Journal, vol. 8, iss. 1, pp. 15-29, 1998.
149
Index
absolute consistency, 8absolute validity interval, 9ACC, 40ACCORD, 13, 63actual CPU utilization, 10actual execution time, 10actuator, 19adaptive feedback control, 21, 85,
114performance, 114
adaptive QoS configurations, 85admission control, 10advice declaration, 12AFC-M-RM, 30AFC-M-STR, 30AOSD, 11API, 52aspect weaving, 11aspects, 11
concurrency, 39documentation, 64FCCA, 41GUARD-Link, 40HP2PL, 39MDMA, 41ODC, 39packages, 39
QACA, 41QoS, 40TRTA, 40UMCA, 41
average inter-arrival time, 10
BMC, 36BOT, 53
CBSD, 11CCF, 83closed-loop, 16coding standard, 57COMET, 14
API, 52aspects, 15building, 64components, 14, 33documentation, 64Testing, 46
COMET configurationsACC, 40GUARD-Link, 40HP2PL, 39MRFC, 41ODC, 39
component
INDEX
exporting state, 82importing state, 82internal state, 67
componentsBMC, 36FCC, 41IMC, 36LMC, 36MMC, 36QAC, 40SMC, 35TMC, 36UIC, 34
concurrencyGUARD-Link, 40HP2PL, 39ODC, 39testing, 51
conformance rule set, 30control variables, 86
controlled, 86controller tuning, 86manipulated, 86
controlled variable, 86controller
tuning, 104controller parameter, 17controller tuning variables, 21, 86
data passing, 63deadline, 7, 10debug
functions, 55levels, 56variables, 57
debugging, 55
tool, 55domino effect, 8dynamic reconfiguration
execution time, 101
EDFdomino effect, 8
EOT, 54estimated CPU utilization, 10
total, 19estimated execution time, 10execution time
actual, 10dynamic reconfiguration, 101estimated, 10measurements, 101
execution time factor, 22
FC-M, 20FC-U, 19FC-UM, 20FCC, 41FCCA, 41feedback control, 16feedback control algorithms, 19feedback control architecture, 86forgetting factor, 25
GUARD-Link, 40
headers, 60advice, 62function, 61struct, 61
HP2PL, 39
IMC, 36
151
interface, 11configuration, 11provided, 11, 75required, 11, 75
invocation period, 10
join point, 11jump table, 66
KOALA, 68
least squares, 23LMC, 36loss function, 24
manipulated variable, 86MDMA, 41mechanism, 13miss ratio, 18MMC, 36MRFC, 41
naming standard, 57
ODC, 39open-loop, 16operation, 13
performance evaluation, 99performance specification, 17pointcut, 11pointcut expression, 11prediction error, 24
QAC, 40QACA, 41QoS aspects
FCCA, 41MDMA, 41QACA, 41testing, 51TRTA, 40UMCA, 41
QoS componentsFCC, 41QAC, 40
QoS configurationsACC, 40MRFC, 41
Quality of Service, 10
real-time database, 8real-time system, 7real-time systems
firm, 8hard, 8soft, 8
reference level, 18, 87regression model, 24regression model algorithm, 23regression variables, 24regressors, 24relative consistency, 9RLS, 24ROBOCOP, 66RTCOM, 13, 63
samplinginstant, 18period, 18window, 18
sampling period, 109scheduling, 8
INDEX
dynamic, 8static, 8
self tuning regulator control, 86SMC, 35software development
aspect-oriented, 11component-based, 11
thread pool, 35time stamp, 9TMC, 36transaction flow, 37transactions, 9
flow, 37update, 9user, 9
transient performance, 106transient response, 17TRTA, 40
UIC, 34UMCA, 41utilization threshold, 22
Avdelning, InstitutionDivision, Department
DatumDate
Sprak
Language
� Svenska/Swedish
� Engelska/English
�
RapporttypReport category
� Licentiatavhandling
� Examensarbete
� C-uppsats
� D-uppsats
� Ovrig rapport
�
URL for elektronisk version
ISBN
ISRN
Serietitel och serienummerTitle of series, numbering
ISSN
Titel
Title
ForfattareAuthor
SammanfattningAbstract
NyckelordKeywords
During the last years the need for real-time database services has increased dueto the growing number of data-intensive applications needing to enforce real-timeconstraints. The COMponent-based Embedded real-Time database (COMET) isa real-time database developed to meet these demands. COMET is developed us-ing the AspeCtual COmponent-based Real-time system Development (ACCORD)design method, and consists of a number of components and aspects, which canbe composed into a number of different configurations depending on system de-mands, e.g., Quality of Service (QoS) management can be used in unpredictableenvironments.
In embedded systems with requirements on high up-time it may not be possibleto temporarily shut down the system for reconfiguration. Instead it is desirableto enable dynamic reconfiguration of the system, exchanging components duringrun-time. This in turn sets demands on the feedback control of the system toadjust to these new conditions, since a new time variant system has been created.
This thesis project implements improvements in COMET to create a more stabledatabase suitable for further development. A mechanism for dynamic reconfigur-ation of COMET is implemented, thus, enabling components and aspects to beswapped during run-time. Adaptive feedback control algorithms are also imple-mented in order to better adjust to workload variations and database reconfigur-ation.
IDA,Dept. of Computer and Information Science581 83 Linkoping
2005-02-16
—
LITH-IDA-EX–05/014–SE
—
2005-02-16
Adaptive QoS Management in Dynamically Reconfigurable Real-TimeDatabases
TITEL
Daniel NilssonHenrik Norin
××
real-time databases, dynamic reconfiguration, quality of service,component-based software development, aspect-oriented software de-velopment, adaptive feedback control
Copyright
SvenskaDetta dokument halls tillgangligt pa Internet - eller dess framtida ersattare - under en lan-gre tid fran publiceringsdatum under forutsattning att inga extra-ordinara omstandigheteruppstar.
Tillgang till dokumentet innebar tillstand for var och en att lasa, ladda ner, skriva utenstaka kopior for enskilt bruk och att anvanda det oforandrat for ickekommersiell forskningoch for undervisning. Overforing av upphovsratten vid en senare tidpunkt kan inte upphavadetta tillstand. All annan anvandning av dokumentet kraver upphovsmannens medgivande.For att garantera aktheten, sakerheten och tillgangligheten finns det losningar av teknisk ochadministrativ art.
Upphovsmannens ideella ratt innefattar ratt att bli namnd som upphovsman i den om-fattning som god sed kraver vid anvandning av dokumentet pa ovan beskrivna satt samtskydd mot att dokumentet andras eller presenteras i sadan form eller i sadant sammanhangsom ar krankande for upphovsmannens litterara eller konstnarliga anseende eller egenart.For ytterligare information om Linkoping University Electronic Press se forlagets hemsidahttp://www.ep.liu.se/
EnglishThe publishers will keep this document online on the Internet - or its possible replacement -for a considerable time from the date of publication barring exceptional circumstances.
The online availability of the document implies a permanent permission for anyone toread, to download, to print out single copies for your own use and to use it unchanged for anynon-commercial research and educational purpose. Subsequent transfers of copyright cannotrevoke this permission. All other uses of the document are conditional on the consent of thecopyright owner. The publisher has taken technical and administrative measures to assureauthenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned whenhis/her work is accessed as described above and to be protected against infringement. Foradditional information about the Linkoping University Electronic Press and its proceduresfor publication and for assurance of document integrity, please refer to its WWW home page:http://www.ep.liu.se/
c© Daniel NilssonHenrik NorinLinkoping, 4th March 2005
