1 MAGISTER Simulation Des Protocoles Dordonnancemen PDF

Ministère de l’Enseignement Supérieur et de la Recherche
Scientifique
École Nationale Supérieure d’Informatique (ESI)
Oued-Smar Alger
É cole Doctorale
Sciences et Technologies de l’Information et de la Communication
MÉMOIRE
Présenté pour l’obtention du diplôme de
MAGISTER
Spécialité : Informatique
Option : Ingénierie des Systèmes Informatiques
Par : M. BERKOUK M OHAMED
Thème
Simulation des protocoles d’ordonnancement

et de contrôle de concurrence pour les SGBD
Temps Réel
Soutenu publiquement le 15 Mars 2012 devant le jury composé de :
Mr. BALLA Amar, Professeur ESI, Président

Mr. AKLOUF Youcef, Maître de conférences A USTHB, Examinateur
Mr. NOUALI Omar, Directeur de recherches CERIST, Examinateur
Mr. HIDOUCI Walid-Khaled, Maître de conférences A ESI, Directeur de thèse

Mr. LOUDINI Malik, Maître de conférences A ESI, Co-Directeur de thèse
DEDICACES
À tous ceux que nous aimons

et ceux qui nous aiment.
A ma famille…
Remerciements
Je tiens à remercier mes Encadreurs
DR Khaled Walid HIDOUCI et DR
Malik LOUDINI pour leurs patiences,
rigueurs, encouragements et conseils.
Ce travail est le fruit de leurs savoir
partagé avec moi.
Mes remerciements sont adressés aux
membres du Jury de Soutenance pour
leurs temps, expertises et orientations.
Je remercie aussi tout le staff de l’ESI
pour leur aide et assistance.
Mohamed BERKOUK
Table de Matières
Introduction Générale 13
CHAPITRE I : Systèmes temps réel et ordonnancement
I.1- Introduction 15
I.2- Systèmes temps réel 15
I.3- Type de systèmes informatiques 16
I.4- Domaine d’application 16
I.5- Structure des systèmes temps réel 16
I.6- Fonctionnement des systèmes temps réel 17
I.7- Caractéristique temporelle des systèmes temps réel 18
I.8- Types des STR 18
I.9- Caractéristiques des STR 19
I.10- Tâche temps réel 20
I.10.1- Introduction 20
I.10.2- Modèles de tâches 21
I.10.2.1- Périodique 21
I.10.2.2- Les tâches sporadiques 22
I.10.2.3- Tâches apériodiques 23
I.10.3- Caractéristiques d’une tâche temps réel 23
I.10.4- Diagramme état-transition d’une tâche 24
I.11- Ordonnancement des tâches 24
I.11.1- Ordonnancement hors ligne 25
I.11.2- Ordonnancement en ligne 25

I.12- Protocoles d’ordonnancement des tâches 26
I.12.1- Algorithmes à priorité fixes 26
I.12.1.1- Algorithmes Rate Monotonic 26
I.12.1.2- L’algorithme d’ordonnancement Deadline Monotonic 27
I.12.2- Les algorithmes à priorité variable 28
I.12.2.1- Earliest Deadline First 28
I.12.2.2 Least Laxity First 29
I.13- Conclusion 30
CHAPITRE II : Systèmes de gestion de bases de données
II.1- Introduction 32
II.2- Introduction aux SGBD 32
II.3- Les transactions pour les SGBD classique 33
II.4- Les propriétés ACID des transactions 34
II.5- Anomalies transactionnelles 35
II.5.1- Perte de mise à jour 35
II.5.2- Mises à jour temporaires ou lecture impropre 36
II.5.3- Lecture non reproductible (fantôme) 36
II.6- Contrôle de concurrence 37
II.6.1- Méthodes optimistes 37
II.6.2- Méthodes pessimistes 38
II.7- Le verrouillage à deux phases 39
II.7.1- La notion d’interblocage 40
II.7.2- La notion de famine 41

II.8- Méthodes par estampillage 42
II.8.1- Ordonnancement total 43
II.8.2- Ordonnancement partiel 43
II.9- Conclusion 45
CHAPITRE III : Systèmes de gestion de bases de données temps réel
III.1- Introduction 47
III.2- Données temps réel 47
III.3- Formalisation de la cohérence 50
III.4- Les propriétés ACID des transactions temps réel 52
III.5- Classement des transactions temps réel 52
III.5.1- Classement des transactions temps réel selon le type d’objet 52
III.5.2- Classement des transactions temps réel selon l’échéance 53
III.6- Qualité de service 55
III.7- Marché des SGBDTR 56
III.8- Conclusion 56
CHAPITRE IV : Protocoles d’ordonnancement et contrôle de concurrence
IV.1- Introduction 59
IV.2- Les protocoles d’ordonnancement et contrôle de concurrence 59
IV.2.1- Techniques optimistes 60
IV.2.1.1- OCC-BC (Optimistic Concurrency Control-Broadcast Commit) 60

IV.2.1.2- Protocole OCC-BC – OPT Sacrifice 61
IV.2.1.3- Protocole OCC-BC – OPT – WAIT 61
IV.2.1.4- Protocole OCC-BC – OPT – WAIT – 50 62
IV.2.1.5- Protocole CCA 62
IV.2.2- Techniques pessimistes 63
IV.2.2.1- Protocoles 2PL – HP 64
IV.2.2.2- Protocoles 2PL – WP 64
IV.2.2.3- Protocole héritage conditionnel de priorité 65
IV.2.2.4- Protocole PCP (Priority Ceiling Prorocol) 66
IV.3- Conclusion 67
CHAPITRE V : Implémentation, test et évaluation
V.1- Introduction 69
V.2- La simulation 69
V.3 Conception du simulateur 69
V.3.1- Présentation d’UML 70
V.3.2- Diagramme de cas d’utilisation 70
V.3.2.1- Représentation graphique 71
V.3.2.2- Description textuelle de ces d’utilisation générale du simulateur 72
V.3.2.3- Diagramme de classe 72
V.3.2.4- Diagramme de séquence 76
V.4- La mise en œuvre 80
V.4.1- Algorithmes de la génération de données 80
V.5- Manuel d’utilisation 83
V.6- Configuration système pour l’intégration du simulateur 90

V.7- Tests 91
V.8- Analyse des résultats 97
V.9- Conclusion 99
Conclusion Générale 100
Bibliographie 102
Liste des Tableaux

I.1 : Exemple d’exécution avec l’algorithme Rate Monotonic 26
I.2 : Exemple d’exécution avec l’algorithme Deadline Monotonic 28
I.3 : Exemple d’exécution avec l’algorithme EDF 29
I.4 : Exemple d’exécution avec l’algorithme LLF

29
II.1 Matrice de compatibilité des verrous 40

III.1 : Nombre d’entités manipulées de certaines applications temps
Réel 48
III.2 : La durabilité des entités de certaines applications temps réel 50
III.3 : Les caractéristiques de cohérence de certaines BDDTR 52
III.4 : Les caractéristiques de cohérence de certaines BDDTR 55
V.1 Les paramètres de bases des tests 92
Liste des Figures
I.1 : Représentation schématique d’un système temps réel 17
I.2 : Modèle de tâches 21

I.3 : Modèle de taches périodiques 22
I.4 : Modèle de taches sporadiques 22
I.5 : Modèle de tâches apériodiques 23

I.6 : Diagramme état-transition des tâches temps réel 24
I.7 : Schéma d’exécution de l’exemple avec l’algorithme Rate Monotonic 27
I.8 : Liste des couleurs utilisées 27
I.9 : Schéma d’exécution de l’exemple avec l’algorithme Deadline
Monotonic 28
I.10 : Schéma d’exécution de l’exemple avec l’algorithme EDF 29

I.11 : Schéma d’exécution de l’exemple avec l’algorithme LLF 30
II.1 Préservation de l’état de cohérence de la base de données 33.

II.2 Perte des mises à jour 35
II.3 Lecture impropre 36
II.4 Lecture fantôme 36
II.5 Les phases d’exécution des protocoles par certification 38
II.6 Schéma d’interblocage 41
II.7 Algorithme d’ordonnancement total pour l’accès à un granule 43
II.8 Algorithme d’ordonnancement partiel pour l’accès en lecture
à un granule 44
II.9 Algorithme d’ordonnancement partiel pour l’accès en écriture
à un granule 44
Figure III.1 : Les types de données manipulés par les SGBDTR 49

Figure III.2 : Echéance stricte et critique 53
Figure III.3 : Echéance stricte non critique 54
Figure III.4 : Echéance non stricte 54
CHAPITRE IV : Protocoles d’ordonnancement et contrôle de concurrence
IV.1 Algorithme OCC-BC-OPT-Sacrifice 61

IV.2 Algorithme OCC-BC-OPT-WAIT 61
IV.3 Algorithme OCC-BC-OPT-WAIT-50 62
IV.4 Algorithme 2PL-WP 65
V.5 Algorithme Héritage conditionnel de priorité 66
V.1 Diagramme cas d’utilisation générale du simulateur 71

V.2 Diagramme de classe du simulateur SGBDTR 73
V.3 processus d’une simulation 77
V.4 : Générer la base de données à simuler. 78
V.5 : Générer la base des transactions temps réel 79

V.6 Algorithme de la génération des données temps réel de base 80
V.7 Algorithme de la génération des données temps réel dérivées 82
V.8 Fiche principale du simulateur 83
V.9 Fiche de simulation 84
V.10 Fiche de paramétrage 85
V.11 Liste de données générées 85
V.12 Liste de dépendances 86
V.13 Paramétrage des transactions temps réel 86
V.14 Liste des transactions temps réel 87
V.15 Spécification des protocoles d’ordonnancement et de contrôle
de concurrence 87
V.16 Fiche des résultats 88
V.17 Fiche état d’évolution d’exécution des transactions 88
V.18 Fiche des états statistiques 89
V.19 Fiche Historique 90
V.20 Réservation des processeurs 91
V.20 bis Définition de priorité 91

V.21 Résultats d’exécution avec les paramètres de base 92
V.22 Résultats d’exécution avec le protocole d’ordonnancement EDF-CR 93

V.23 Résultats d’exécution avec contrôleur de concurrence 2PL-WP 93
V.24 Résultats d’exécution avec contrôleur de concurrence OCC-BC 94
V.25 Résultats d’exécution avec contrôleur de concurrence WAIT-50 94
V.26 Résultats d’exécution avec changement de temps d’une écriture 95
V.27 Résultats d’exécution avec changement du nombre de données
TR de base 95
V.28 Résultats d’exécution avec changement du nombre de données
TR dérivées 96
V.29 Résultats d’exécution avec changement de validité de données
TR 96
V.30 Résultats d’exécution avec changement de nombre de dépendances des
données temps réel dérivées 97
Résumé :
Les systèmes temps réel sont utilisés de plus en plus dans la vie et dans
plusieurs domaines, tout en respectant l’échéance d’exécution des tâches. Ceci
représente un grand enjeux. Plusieurs applications temps réel utilisent une grande
quantité de données, ce qui nécessite des mécanismes qui ne sont pas fournis par
les systèmes temps réel. Elles sont fournies par les SGBD. Un système temps réel
manipule des données classiques et données temporelles de base ou dérivées . Les
SGBD classiques ne peuvent pas garantir le respect des contraintes temporelles,
ce qui a permis de donner une naissance pour les Système de gestion des bases de
données temps réel (SGBDTR). Les travaux effectués sur le contrôle de
concurrence des transactions dans les SGBDTR s’appuient sur les techniques de
contrôle de concurrence appliquées dans les SGBD classiques et sur les
techniques d’ordonnancement des tâches dans les systèmes temps réel.
Notre travail consiste à la mise en œuvre d’un simulateur pour évaluer les
différents protocoles d’ordonnancement et contrôle de concurrence.
Abstract
Real Time Systems are used more and more in several domains while
respecting the time frame allocated for each task. This is the biggest stake and
challenge. Several applications use a huge amount of data which require a number
of mechanisms that are not made available by Real Time Systems. These are made
available by DBMS. A Real Time System manipulate classical data as well as
database or derived temporal data . Classical DBMSs cannot guarantee the
respect of temporal constraints. This has yielded Real Time DBMS.
Research done on controlling competing transactions (concurrency control) in

RTDBM used a number of techniques of concurrency control used in classical
DBMS and from task scheduling techniques used in Real Time systems.
This research aims to develop a simulator in order to evaluate the different

scheduling protocols and concurrency control.
Mots clés: Système temps réel , SGBD Temps réel, Données temporelles ,
Protocoles d’ordonnancement et contrôle de concurrence.
Keywords : Real Time System, Real Time DBMS, Temporal Data, Scheduling
Protocols, Concurrency Control
INTRODUCTION
GÈNÈRALE
Introduction générale
Introduction Générale
Plusieurs applications temps réel utilisent des quantités importantes de
données temps réel comme les applications destinées pour le contrôle du trafic
aérien, contrôle des centrales nucléaires, des applications de commerce
électronique, systèmes multimédia etc. Ces applications contrairement aux systèmes
classiques doivent garantir l’attribution des résultats dans des délais limités. Ces
applications doivent manipuler des données temps réel soient des données
sensorielles qui proviennent de l’environnement contrôlé par le système ou des
données dérivées calculées à partir d’autres données. Ce qui signifie que dans les
SGBDTR (Système de Gestion de Bases de Données Temps Réel), les données
représentent la capture de l´état du monde réel.
La gestion d’une grande quantité de données nécessite des mécanismes

qui ne sont pas fournis par les systèmes temps réel mais par les SGBD
(Système de Gestion des Bases de Données). Les systèmes de gestion de bases
de données assurent le respect des contraintes d’intégrité et de cohérence, la
possibilité de partager des données, la reprise après les pannes..
Vue l’existence des conflits d’accès aux données, les SGBD classiques
utilisent des algorithmes pour le contrôle de concurrence. Les techniques de
transactions sérialisables utilisées par les systèmes de gestion de bases de
données classiques, ne sont pas applicables pour les bases de données temps
réel car les transactions qui ne respectent pas leurs échéances doivent être
rejetées car on ne doit pas seulement respecter les contraintes logiques mais
aussi les contraintes temporelles. Donc, pour pouvoir répondre aux deux
contraintes au même temps, un nouveau type de système de gestion de base
de données a connu le jour c’est les SGBD Temps Réel [RAM93a]. Les SGBD
Temps Réel utilisent des techniques de contrôle de concurrence de bases de
données traditionnelles pour contrôler les accès concurrents au même granule de
donnée d’une part et d’autre part utilisent des techniques d’ordonnancement de
Page 15
Introduction générale
tâches des systèmes temps réel dans le but d’ordonnancer les transactions afin
de garantir leur exécution avant la fin de leurs échéances.
L’objectif de notre travail est la simulation des protocoles d’ordonnancement et

de contrôle de concurrence pour les SGBD Temps Réel en tenant en compte des
données temps réel dérivées.
Les simulations informatiques sont devenues incontournables pour la

modélisation des systèmes naturels en physique, chimie et d’autre. Ici, la simulation
permettra d’appliquer certains protocoles d’ordonnancement et contrôle de
concurrence concernant les transactions temps réel. La création d’un simulateur
nécessite une conception pour définir les besoins, décrire les données à automatiser
et définir le modèle logique de traitement du simulateur à développer.
Le présent mémoire est organisé en cinq chapitres :
Le premier chapitre présente les notions de base concernant les systèmes

temps réel et les différents protocoles utilisés pour l’ordonnancement des tâches.
Par la suite, le deuxième chapitre définit les systèmes de gestion de bases de

données et décrit les différentes caractéristiques de ces systèmes et les différents
protocoles de contrôle de concurrences utilisés par ces derniers.
Le troisième chapitre présente l’objectif des systèmes de gestion de bases de

données temps réel et leurs spécificités par rapport aux SGBD classiques.
Le quatrième chapitre développe les différents protocoles d’ordonnancement

des transactions temps réel et les différentes méthodes appliquées pour le contrôle
de concurrence aux données.
Le cinquième chapitre présente la partie conception avec l’utilisation de

langage UML, la mise en œuvre du simulateur et les résultats des tests.
Un conclusion générale clôture ce mémoire.
Page 16
CHAPITRE I
SYSTEMES TEMPS REEL

ET
ORDONNANCEMENT
Chapitre I Système Temps Réel
1. Introduction :
Le statut dynamique du procédé des applications temps réel nécessite que le

système informatique doit répondre aux contraintes temporelles de l’exécution des
taches (opérations) de l’environnement physique des applications, ce qui oblige
d’avoir un système capable de minimiser le nombre des tâches hors échéances par
l’utilisation souvent des algorithmes d’ordonnancement.
Un système classique valide dépend uniquement de l’exactitude des résultats

fournis après l’exécution de la tâche quelque soit la durée de traitement ce qui
indique que la caractéristique fondamentale de ce type de système c’est la validité
des résultats , contrairement à un système en temps réel où la caractéristique
fondamentale c’est le facteur de temps ce qui nécessite d’avoir des résultats valides
avant la fin d’échéance de la tâche pour éviter de graves conséquences en cas de
dépassement de délai [STA 88].
Ce chapitre traite deux parties. La première présente les données de base sur
les systèmes temps réel et la deuxième concerne les principes d’ordonnancement
des tâches temps réel.
I.2 Systèmes temps réel :
Un système temps réel est un système réactif où ses applications doivent

réagir avant une échéance donnée. Cette propriété distingue globalement ce type
d’application par rapport aux autres types d’applications informatiques. Cet exemple
illustre cette différence, le calcul de la position d’un missile en mouvement représente
un système temps réel, même si le résultat fourni après la fin d’échéance est exact
[STA 88], ce résultat est considéré comme erroné car l’objet a changé de position
par contre pour un système classique comme la gestion des notes si les moyennes
calculées sont exactes alors le système est en bon fonctionnement.
I.3 Type de systèmes informatiques :
Il existe trois types de systèmes informatiques qui sont [STA 88] :
Systèmes transformationnels : les données sont disponible au lancement. Le

temps du traitement pour l’élaboration des résultats ne sont pas contraints. Ce
18
type du système est utilisé dans les calculs scientifiques et gestion de bases de
données.
Systèmes interactifs : aucune dépendance temporelle mais les données

d’entrées sont produites par l’environnement sous différents modes d’acquisition
(saisie, clique souris, chargement fichier…etc.). Ce type de système est utilisé
pour les outils bureautiques ou systèmes transactionnels.
Système réactif : c’est un système temporel. Les données d’entrées sont

produites par l’environnement physique. La réaction du système informatique est
sous contrainte temps. Ce type du système concerne les systèmes temps réel.
I.4 Domaine d’application :

Les systèmes temps réel recouvrent une gamme d’applications très large et
variée, du système simple comme les systèmes Airbag jusqu’aux systèmes
complexes comme le suivi de satellites. Voici certains domaines où on trouve les
systèmes temps réel :
Le domaine médical
Le domaine militaire
Le contrôle aérien
Le domaine de télécommunication
Le contrôle d’équipements
Le domaine aérospatial
Le multimédia
Le domaine industriel
I.5 Structure des systèmes temps réel [GRO 99] :
Un système temps réel est un système informatique réactif en relation avec

l’environnement physique externe par l’intermédiaire des capteurs permettant
d’acquérir des informations sur l’environnement contrôlé, selon ses informations le
19
système doit décider des réactions pendant un temps limité (échéance du temps)
pour assurer un état stable du système.
Un système temps réel est composé de deux éléments, l’environnement

physique (le procédé) et le système contrôleur qui représente un système
informatique. Ce dernier agit sur le procédé à l’aide des actionneurs.
Un système informatique destiné à commander ou à superviser des opérations

est composé, le plus souvent, d’une ou plusieurs unités de traitement (des
ordinateurs ou des automates programmables), des capteurs, des actionneurs, des
périphériques de visualisation et de dialogue avec les opérateurs.
Le schéma suivant montre la structure des systèmes temps réel :
Capteurs Système
Procédé informatiqu
Actionneurs e
Figure I.1 : Représentation schématique d’un système temps réel [COT 05]
I.6 Fonctionnement des systèmes temps réel [GRO 99] :
Le fonctionnement général des applications temps réel est comme suit :
Acquisition de données depuis l’environnement physique à l’aide des caméras,

capteurs (sensors) ou autres dispositifs d’acquisition sous la forme des
interruptions ou des mesures.
Traitement des données acquises et l’élaboration des résultats avant un délai

limité.
Attribution des ordres de commande aux actionneurs pour agir sur le procédé
physique (modification de l’état physique du système) ou attribution des
ordres d’affichage uniquement.
Un exemple d’application est celui de la commande d’une chaîne d’assemblage

de véhicules composée d’un ensemble de robots, convoyeurs et la station
d’assemblage.Les robots sont dotés de caméras, dans le but d’acquérir des données
sur la position des objets à transporter par les convoyeurs. La durée d’acquisition des
20
caractéristiques de l’objet doit se terminer avant la disparition de l’objet. Ce qui

permet de dire que l’action possède une échéance.
I.7 Caractéristique temporelle des systèmes temps réel :
Le respect des contraintes temporelles d’une application temps réel dépend de la

dynamique de l’environnement à contrôler.
L’unité de la contrainte temporelle peut être très différente suivant l’application
[COT 05].
Milliseconde : Systèmes radar, systèmes vocaux…
Seconde : systèmes de visualisation, robotique…
Minute : chaine de fabrication…
I.8 Types des STR :
Les STR sont classés selon la notion de criticité [MAN 99] :
Les applications à contraintes temporelles strictes « hard » : la réponse du

système dans les délais est vitale où le non respect de ces contraintes peut
engendrer des dégâts humains et matériels . Dans ces STR, on cherche à ce
que toutes les échéances soient respectées. Ce type de système est utilisé
comme exemple pour le contrôle aérien, le contrôle d’une centrale nucléaire.
Les applications à contraintes temporelles relatives «soft», où le dépassement

des échéances est considéré comme une faute légère. Dans ces STR "mou",
on cherche à minimiser le retard d’exécution.
Les applications mixtes (Firm), où on trouve des tâches avec des contraintes
strictes et d’autre souple. La réponse du système dans les délais est
essentielle. Le résultat ne sert plus à rien une fois le délai est dépassé comme
par exemple les transactions en bourse.
21
I.9 Caractéristiques des STR [WAN 02] :

Caractéristiques des systèmes temps réel sont :
La prévisibilité : un STR doit être conçu tel que ses performances soient
définies dans le pire des cas. Contrairement aux systèmes classiques où les
performances sont définies en termes de moyenne.
L’ordonnancement : choix d’une politique d’ordonnancement des activités de

façon à ce que le système soit prévisible.2
Le déterminisme : ce doit être un but à atteindre pour assurer la prévisibilité : il

faut enlever toute incertitude sur le comportement des activités d’une façon
individuelles et mises ensembles.
Le déterminisme absolu est difficile à atteindre dû aux sources du non

déterminisme comme les fautes matérielles et logicielles.
Le non faisabilité des composants rend la prévision du comportement du

système très difficile, donc il est nécessaire de concevoir des systèmes tolérants aux
fautes tels que les systèmes temps réel embarqués.
Une autre caractéristique importante est que la majorité des systèmes temps
réel sont embarqués : ils sont des composants d’un grand système qui interagit avec
le monde physique. Ceci peut être la source primaire de la complexité de ces
systèmes, car le monde physique se comporte d’une manière indéterminée avec des
événements concurrents qui arrivent d’une manière asynchrones. Donc les systèmes
doivent aussi être concurrents et résoudre les problèmes de synchronisation. Les
systèmes embarqués sont utilisés dans plusieurs domaines soit militaire, médicale
ou d’autre et la majorité sont distribués.
I.10 Tâche temps réel :
I.10.1. Introduction [CLI 92] :
Le temps de basculement de contexte (Latency time) est un facteur de

qualité de l’ordonnanceur. Plus ce temps est faible plus on garantit l’ordonnancement
des tâches, car ce temps est considéré comme du temps perdu, où il ne se
passe rien d'efficace.
22
Une tâche est une activité qui consomme des ressources de la machine
informatique (RAM, CPU). Une tâche temps réel représente l’unité de base des
programmes temps réel. Les taches temps réel sont des entités qui composent un
programme d’un système temps réel.
Les tâches temps réel sont associées à des traitements d’entrées sorties ou
des calculs.
une tâche temps réel est caractérisée par un ensemble de critères temporels
caractérisé par la date de réveil qui représente le moment de déclenchement de la
requête d’exécution dans laquelle la tâche devient ordonnançable. Le
déclenchement de la tâche peut être interne selon une période d’horloge ou externe
(interruption ou déclenchée à partir d’une autre tâche). Sa durée maximale
d’exécution qui représente le délai d’occupation du micro processeur (Figure I.2) ,
cette période est caractérisée par C et son délai maximal acceptable pour son
exécution D (temps de réponse maximal réservé à la tâche pour se terminer). La
figure suivante résume ces différentes propriétés temporelles. Des relations de
précédences peuvent être définies pour indiquer des restrictions sur l'ordre
d'exécution des tâches. Les tâches peuvent aussi partager des ressources (autre
que le processeur) et ces contraintes doivent être spécifiées et respectées par le
système.
La figure suivante représente un modèle de tâches
C
Temps
r tde tfe d
Figure I.2 : Modèle de tâches [GRO 99]
C (temps d’exécution) = tfe (temps fin d’exécution) - tde (temps début d’exécution).
d (échéance) = r+D
23
I.10.2 Modèles de tâches :

Le type des tâches est spécifié selon la période entre deux séquences
d’activation pour cela on trouve :
I.10.2.1 Périodique :
Les tâches périodiques représentent les tâches récurrentes dont les

séquences d’activation successives sont séparées par une période constante. La
nécessité d’utilisation de ce type de tâches est justifiée vu l’état dynamique de
l’environnement qui nécessite une surveillance régulière et vu le problème
concernant l’acquisition continue des informations sur le procédé contrôlé via les
capteurs. Pour cela, on doit spécifier un intervalle de fonctionnement des capteurs .
Cette intervalle doit garantir une meilleur surveillance de l’évolution de
l’environnement concerné.
La cadence est définie selon le contexte du système contrôlé. Pour le système

radar l’échantillonnage est mesuré en microseconde par contre pour certaine chaine
de fabrication la minute représente l’unité d’échantillonnage. Ce principe de
fonctionnement concerne ce type de taches pour cela on dit qu’une tache est dite
périodique si celle-ci est activée régulièrement après chaque intervalle de temps
[LIU 73].
Une tâche temps réel périodique τi est défini par Le quadruple (ri,Ci,Di,Pi) , le
R concerne le temps de déclenchement , la propriété C concerne la durée
d’exécution , D représente la durée maximal d’exécution et P est la durée entre deux
activations ( Période d’échantillonnage) .
P (Reactivation) P
D D
C C
Temp
r0 d0 r1 d1 r2
Figure I.3 : Modèle de taches périodiques [GRO 99]
24
I.10.2.2 Les tâches sporadiques :

Les tâches sporadiques sont des tâches récurrentes avec des contraintes
strictes d’échéance, Le modèle des tâches sporadiques peut être généralisé de la
même façon que le modèle de tâches périodique sauf que la durée entre deux
activations successive est caractérisée par une durée minimale.
P1 (Réactivation) Minimum P2
D D
C C
0 Temp
r0 d0 r1 d1 r2
Figure I.4 : Modèle de taches sporadiques [GRO 99]

I.10.2.3 Tâches apériodiques
Une tâche est dite apériodique si le temps minimal entre deux activations est
inconnu. Un système temps réel stricte valide ne doit pas contenir ce type de tâches,
car en général. Ce modèle est représenté par le schéma suivant :
P (Reactivation) Aléatoire P
D D
C C
Temp
r0 d0 r1 d1 r2
Figure I.5 : Modèle de tâches apériodiques [GRO 99]
I.10.3 Caractéristiques d’une tâche temps réel : [RAH 08]
Préemptible : est une tâche active qui peut être arrêtée temporairement pour
que le processeur exécute une autre tâche de priorité supérieure.
25
Non Préemptible : Une fois la tâche activée aucune autre tâche même de
priorité supérieure ne peut être interrompue jusqu’à sa fin d’exécution.
Tâche indépendante : c’est une tâche isolée, qui n’a aucune relation de
précédence avec d’autre tâches et ne partage aucune ressources aves les
autre tâches.
Tâches dépendantes : par une relation de précédence statique : si elles

agissent selon un ordre prédéterminé, ou induit par la communication par
messages ou par une relation explicite de synchronisation. Par une relation de
précédence.
I.10.4 Diagramme état-transition d’une tâche :
Une instance de tâche peut avoir pendant sa durée de vie les états décrits
dans le schéma suivant (Fig I.6) :
A tout instant, une tâche a un état. On dit que la tâche est :
Endormie (asleep) : représente l’état d’attente d'événements pour engendrer

le réveil de la tâche, l’événement peut être généré par une horloge, un
message ou une interruption.
Prête (ready) : c’est une tâche en attente d’activation par l’ordonnanceur.
Active (running) : c’est une tâche en cours d’exécution.
L'ordonnanceur de tâches bascule le traitement d'une activité sur une autre en

passant la tâche active dans l'état prête ou endormie, et une tâche de l'état prête ou
endormie à l'état active.
Fin
Réveil Èlection Elu

Prêt
Blocage
Déblocage
Bloqué
Figure I.6 : Diagramme état-transition des tâches temps réel [CAZ 08]
26
I.11 Ordonnancement des tâches :
Le système informatique des systèmes temps réels représente un ensemble

d’activités (taches) communicantes et partageant des ressources. Le système
informatique doit gérer les dépendances entre les tâches et la concurrences de ces
dernières pour l’utilisation des ressources . Ce module est appelé ordonnancement
[COT 05].
La stratégie d’ordonnancement représente un ensemble de règles

définissant l’ordre d’exécution des tâches manipulant certaines ressources liées à un
processeur.
L’utilisation d’un tel algorithme doit tenir en compte certaines propriétés :
Tâches périodiques ou apériodiques
Système avec préemption ou non
Système à priorité fixe ou variable
On classe les protocoles d’ordonnancement en deux catégories :
I.11.1 Ordonnancement hors ligne :
La séquence d’exécution complète est définie à la base des paramètres

temporels des tâches à la conception puis déroulée pendant l’exécution [BEN 05].
Le résultat de l'ordonnancement est stocké dans une structure de données utilisée
par le séquenceur en revanche l’application est figée, l’ordonnancement à coût
temporel négligeable. Ce type d’ordonnancement est utilisé pour les systèmes très
simple et ne tient pas en compte les événements non prévus.
L’exécution des tâches pour ce type est synchrone car l’ordre d’exécution se
fait en séquence non interrompue.
I.11.2 Ordonnancement en ligne :
Le choix de la prochaine tâche à exécuter est dynamique, il se fait à la base

des paramètres de la tâche, l’ordonnancement pour ce type à un coût non
négligeable , par contre le système informatique peur réagir à des événements non
prévus [AUD 91].
27
L’exécution des tâches pour ce type peut être asynchrone car on peut avoir
des événements externe non prévus qui engendrent l’interruption des tâches.
Pour notre travail, on s’intéresse aux systèmes asynchrones composés de

tâches préemptibles.
I.12 Protocoles d’ordonnancement des tâches :
On classe les algorithmes d’ordonnancement en deux classes : algorithmes à

priorité fixe et algorithmes à priorité dynamique.
Il existe plusieurs algorithmes d’ordonnancement. On présentera les

algorithmes largement utilisés.
I.12.1 Algorithme à priorité fixe :
Pour ce type d’algorithme, l’ordre de priorité des tâches est fixe durant
l’exécution.
Pour ce type d’algorithmes, on présente les deux algorithmes suivants Rate
Monotinic et Deadline Monotonic.
I.12.1.1 Algorithme Rate Monotonic [LIU 73]:
C’est un algorithme classique qui s’applique pour :
les tâches périodiques.
Les tâches indépendantes (aucune communication entre les tâches).
L'échéance de la tâche est considérée comme la fin de la période.
Les tâches sont préemptibles.
La priorité est affectée selon leurs fréquences, c'est-à-dire la tâche qui
possède le P (périodicité) minimale aura le niveau de priorité maximum.
Pour que le système des tâches soit ordonnaçable, on doit vérifier la
condition suivante :
n
∑ Ci /Pi ≤n (21/n-1)
I=0
Exemple
Soit la liste des tâches suivantes :
28
Tâche C P D Priorité
1 3 10 10 2
2 2 6 6 3
3 2 20 20 1
Tableau I.1 : Exemple d’exécution avec l’algorithme Rate Monotonic
Pour que cette liste de trois tâches soit ordonnançable par cet algorithme on doit
vérifier la condition précédente
D’après ce tableau, la tâche 2 est la plus prioritaire car son P est le minimum.
Ainsi cette liste est ordonnançable car

(3/10)+ (2/6) + (2/20) ≤3 (21/3-1)
Ce qui donne 0.73≤ 0,78
Le schéma d’exécution pour cet exemple avec l’algorithme Rate Monotonic

est le suivant :
T1
T2
T3
Temps 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Figure I.7 : Schéma d’exécution de l’exemple avec l’algorithme Rate Monotonic
Légende des couleurs utilisées
Prêt En exécution Endormie Interrompu
Figure I.8 : Liste des couleurs utilisées
1.12.1.2 L’algorithme d’ordonnancement Deadline Monotonic (DM)
C’est un algorithme qui s’applique pour :

les tâches périodiques
Les tâches indépendantes (aucune communication entre les tâches).
L'échéance de la tâche est inférieure ou égale à sa période.
Les tâches sont préemptible.
29
La priorité est affectée inversement proportionnelle à son échéance, c'est-à-

dire la tâche qui possède l’échéance minimum aura le niveau de priorité maximum.
[LEU 82] :
Pour que le système des tâches soit ordonnaçable, on doit vérifier la condition
suivante :
n
∑ Ci /Di ≤n (21/n-1)
I=1
Exemple :
Tâche C P D Priorité
1 2 8 6 3
2 3 10 10 2
3 2 20 20 1
Tableau I.2 : Exemple d’exécution avec l’algorithme Deadline Monotonic
Alors 1ère tâche (D=6) plus prioritaire que la 2ème tâche (D= 10) et cette
dernière plus prioritaire que la 3ème tâche (D=20).
Ainsi cette liste est ordonnaçable car (2/6) + (3/10) + (2/20) ≤ 3(21/3-1)
Ce qui donne 0.73 ≤0.78
Le schéma d’exécution pour cet exemple avec l’algorithme Rate Monotonic

est le suivant :
T1
T2
T3
Période 0 1 2 3 4 5 6 7 8 9 10 11 12 13
Figure I.9 : Schéma d’exécution de l’exemple avec l’algorithme Deadline Monotonic
I.12.2 Les algorithmes à priorité variable :
Pour ce type d’algorithme, l’ordre de priorité des tâches est variable selon
l’urgence des tâches.
Dans cette classe d'algorithmes, l'ordre de priorités des tâches peut changer
durant l'exécution en assurant chaque fois que la tâche la plus urgente qui sera
exécutée le plutôt.
30
I.12.2.1 Earliest Deadline First (EDF)

C’est un algorithme qui attribue la priorité élevée à la tâche ayant l’échéance
la plus proche [JAC 55].
Pour des tâches à échéance sur requête, une condition nécessaire et suffisante
d’ordonnancement est :
n
∑ Ci /Pi ≤1
I=1
Exemple
Tâche C P D
1 2 6 6
2 2 8 8
3 3 12 12
Tableau I.3 : Exemple d’exécution avec l’algorithme EDF
Ainsi cette liste est ordonnaçable car (2/6)+(2/8)+(3/12) ≤ 1,Ce qui donne
0.83 ≤1
T1
T2
T3
Période 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Figure I.10 : Schéma d’exécution de l’exemple avec l’algorithme EDF
I.12.2.2 Least Laxity First (LLF):

C’est un algorithme à priorité dynamique [MOK 83]. Cet algorithme assure le
processeur à la tâche ayant la plus courte marge. Cette laxité est calculée à partir
de temps d’exécution restant (Li) à un instant t et le temps restant pour la fin de la
durée d’échéance restant, la priorité est attribuée inversement proportionnelle à la
valeur de la marge résultat.
Tâche C P D
1 2 6 6
2 2 8 8
3 3 12 12
Tableau I.4 : Exemple d’exécution avec l’algorithme LLF
31
T1
T2
T3
Période 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Figure I.11 : Schéma d’exécution de l’exemple avec l’algorithme LLF
Il existe d’autres protocoles concernant les tâches apériodiques et sporadiques

comme les algorithmes avec traitement en arrière plan [SAD 04].
I.13 Conclusion :
Les systèmes temps réel sont utilisés de plus dans plusieurs domaines. Le
respect d’échéance d’exécution des tâches représente le grand enjeu.
Les tâches temps réel partagent une ressource qui est représentée par le micro
processeur. Ainsi pour garantir l’exécution du maximum de tâches sans dépasser les
délais, plusieurs algorithmes d’ordonnancement sont développés pour mieux
partager le micro processeur.
Il existe d’autres systèmes temps réel, où il y a d’autres ressources que le
processeur représenté par les données.
La gestion d’une grande quantité de données nécessite des mécanismes qui

ne sont pas fournis par les systèmes temps réel mais sont fournies par les SGBD
(Système de Gestion des Bases de Données).
Le prochain chapitre donne les différentes caractéristiques des SGBD et les

mécanismes de contrôle de concurrence de données.
32
CHAPITRE II
SYSTÈMES DE GESTION
DE
BASES DE DONNÉES
Chapitre II Systèmes de gestion de bases de données
II.1 Introduction :
Vue la nécessité de stocker et manipuler une masse importante de données

dans la majorité des systèmes temps réel, on est obligé de présenter les capacités
des systèmes de gestion des bases de données pour la manipulation de ce type de
données.
Vue l’existence des conflits d’accès aux données, les SGBD utilisent des
algorithmes pour la gestion des concurrences. Ce chapitre présente deux points. Le
premier sert à décrire les caractéristiques principales des systèmes de gestion des
bases de données. Le second est la présentation des différentes méthodes
appliquées pour le contrôle des concurrences entre les transactions.
II.2 Introduction aux SGBD :
Un SGBD est un système qui permet d’interagir avec la base de données. Il

permet à un utilisateur de définir les données, de consulter la base et de la mettre à
jour. Un des aspects essentiels de ces systèmes est qu’ils s’avèrent utiles pour gérer
de manière efficace un important volume de données. L’objectif de performance des
SGBD est de maximiser le débit général des transactions, sans se soucier du temps
d’exécution d’une requête individuelle. Leur objectif de qualité est d’assurer l’intégrité
des données.
Dans les SGBD classiques, il n’est pas tenu compte des contraintes
temporelles des transactions. Il peut donc arriver que le temps de réponse de
certaines transactions soit très important, ce qui n’est pas acceptable dans une
application temps réel où chaque transaction doit s’exécuter durant un intervalle de
temps précis.Les deux premières générations de SGBD (les modèles hiérarchiques
et réseaux) ont remédié à ces différents problèmes mais ils sont étroitement liés aux
supports physiques.
Dans la fin des années 1970, les SGBDR (relationnel) sont apparus. Cette
génération de SGBD assure l’indépendance entre les données et les traitements.
Ainsi avec leurs langages de manipulation comme SQL (Structured Query Langage),
l’utilisateur manipule la base en spécifiant ce qu’il veut (QUOI) et non COMMENT

l’obtenir [GAR 00].
34
L’objectif des SGBD est d’atteindre une certaine efficacité de gestion de

données et d’optimiser le temps de réponse moyen des transactions, donc, les
SGBD ne se préoccupent pas des temps de réponse individuels des transactions,
par contre les STR se préoccupent de l'ordonnancement des tâches pour favoriser le
respect des échéances pour chaque tâche.
Un des problèmes des différentes générations de SGBD est le contrôle de
concurrence de l’accès aux données dans le cas de plusieurs transactions.
II.3 Les Transactions pour les SGBD classique:
Une transaction correspond à la vision d’un programme d’utilisateur du côté

du SGBD, c’est une séquence atomique d’opération de lectures/écritures dans la
base de données [BOU 06].
Le SGBD doit garantir l’état cohérent de la base après l’exécution d’une

transaction, car une transaction est composée d’une suite d’instructions qui
réussissent ou qui échouent en totalité (pas de réussite partielle). Si elle réussit, les
modifications apportées à la base sont permanentes, et la transaction est inscrite au
journal. Si une instruction échoue, toute la transaction est annulée et la base
retrouve l’état initial dans lequel elle était avant la transaction [SOU 08].
Toutes les transactions figurent dans un fichier que l’on appelle le journal des
transactions. Le SGBD annule les différentes modifications, ce qui rend la base à
l’état cohérent initial.
E1 E2
Transaction validée
Etat cohérent Etat cohérent
T1 T2 Temps
Figure II.1 Préservation de l’état de cohérence de la base de données [PHI 99].
35
II.4 Les propriétés ACID des transactions [ESW 76]:

Les quatre principes ACID sont l'atomicité, la cohérence, l'isolement et la
durabilité.
Atomicité : cette propriété utilise le principe du tout ou rien, c'est-à-dire toutes les
actions de la transaction s’exécutent avec succès, ou pas du tout, cette propriété
garanti qu'il n'y a que deux résultats possibles pour une transaction qui implique des
changements de multiples ensembles de données interdépendants : soit toutes les
opérations ont été réalisées avec succès et le résultat peut être validé dans la base
comme une seule entité ou, si l'une des opération n'a pas été réalisée avec succès ,
toutes les autres opérations doivent être annulées (Rollback),ce qui engendre de
passer à l’état initial cohérent de la base.
La Cohérence : Une transaction fait passer la base d’un état cohérent dans un
autre état cohérent. Ce qui signifie la capacité du moteur de bases de données à
protéger la base de tous les changements d'état qui pourraient laisser un ensemble
de données désynchronisé par rapport à un autre ensemble de données. Par
exemple, le système doit être capable de reconnaître qu'une clé étrangère est liée à
une clé primaire existante. Il doit être capable d'empêcher la suppression d’une clé
primaire si cette dernière possède des tuples fils.
Isolation : Décrit la possibilité du moteur de bases de données afin de permettre

à chaque transaction d'opérer comme s'il était la seule transaction. Le mécanisme
d'isolement doit être capable de garder la base cohérente pour chaque transaction
tant qu'elle est en cours, indépendamment de tout changement intervenant dans
d'autres transactions.
Durabilité : les effets de l’opération commit sur la base deviennent permanents,

même si un incident survient juste après le commit, la résolution de ce type de
problème est assuré par l’utilisation le journal (log), ce journal permet de restaurer la
base de données en cas de panne sur le ou les fichiers de données. Ces fichiers de
données sont évidemment sauvegardés régulièrement, mais pour pouvoir restaurer
complètement la base en cas de plantage il faut pouvoir refaire toutes les
modifications depuis la dernière sauvegarde. C’est le rôle du journal des transactions
de contenir toutes ces informations. Il est donc généralement stocké sur un autre
disque.
36
II.5 Anomalies transactionnelles
Un des plus grands problèmes pour assurer la cohérence d’une base vient du
fait qu’il doit être possible d’avoir les accès simultanés aux mêmes ressources d’une
base. Ce qui engendre un certain type de problèmes [GAR 84] :
II.5.1 Perte de mises à jour :

Le problème apparaitra lorsque deux mises à jour s’effectues en parallèle avec
un temps déféré sur le même granule implique que la nouvelle donnée de ce
granule reçoit le résultat de la dernière mise à jour ce qui engendre que la mise à
jour de la première transaction est perdue.
On suppose que deux virement bancaire s’effectuent en même temps pour un
compte x, le montant de ce compte à l’instant T0 est 10000 DA
La première transaction du premier virement est la suivante :

Update compte
Set montant compte=montant compte + 5000
Where numero_compte=’X’
La deuxième transaction du deuxième virement est la suivante :
Update compte
Set montant compte=montant compte+20000
Where numero_compte=’X’
On suppose l’exécution suivante :
Période Transaction 1 Transaction2

T1 Lire (X)
T2 Lire (X)
T3 Ecrire x=x+500
T4 Ecrire X=X+20000
Figure II.2 Perte des mises à jour [GAR 84]
Le montant du compte après l’exécution des deux transactions est 30000 DA

et normalement le montant c’est 35000 DA, cette erreur est dûe au perte de la mise à
jour de la première transaction (écrasée par celle de deuxième transaction).
37
II.5.2 Mises à jour temporaires ou lecture impropre:

Le problème apparaitra lorsque une transaction consulte une valeur temporaire
(non validée), se qui implique dans le cas d’annulation des mises à jours de la
première transaction alors la valeur de ce granule au niveau de la deuxième
transaction est non propre.
Exemple : pour x = 10000
Temps Transaction1 Transaction 2

T1 Lire (x)
T2 Ecrire X=x+5000
T3 Lire (X)
T4 Annulation Ecrire x=x+20000
Figure II.3 Lecture impropre [GAR 84]
Le montant du compte après l’exécution des deux transactions est 35000 DA

et normalement le montant c’est 30000 DA, cette erreur est due à la consultation
réalisée par la transaction d’un granule en mise à jours temporaire et cette dernière
est annulée ensuite sans aucune modification au niveau de la deuxième transaction.
II.5.3 Lecture non reproductible (Fantôme) :

Ce problème se produit lorsqu’une la transaction exécute une requête qui
recherche un ensemble de tuples de la base de données, puis après un peu de
temps la même requête est exécutée, renvoie d’autre tuples en plus, ce qui indique
que ces nouveaux enregistrements (fantôme) sont insérés entre temps par une
autre transaction.
Temps Transaction1 Transaction 2

T1 Lire (x)
T2 Lire (x)
T3 Ecrire x=x+val
T4 Lire(x)
Figure II.4 Lecture fantôme [GAR 84]
38
II.6 Contrôle de concurrence :

Lorsque plusieurs transactions tentent d’accéder à un granule en mode
incompatible (lecture/écriture, écriture/lecture, écriture/écriture) dans une base de
données en même temps, il convient d'implémenter un système de contrôle de
manière à ce que les modifications apportées par une transaction n'en pénalisent
pas une autre. Ce système s'appelle le contrôle de concurrence.
Les protocoles de concurrence utilisés dans les SGBD ont comme notion de
base de respecter la sérialisabilité d’exécution des transactions pour garantir
l’exécution correcte des transactions.
Le principe de sérialisabilité c’est de ne laisser s’exécuter les transactions en

parallèle que celles provoquant les mêmes effets sur les données qu’une exécution
en séquence de ces mêmes transactions [BER 87].
La théorie du contrôle de concurrence repose sur deux méthodes de

classification : les protocoles pessimistes et les protocoles optimistes.
II.6.1 Méthodes optimistes :
Sont dites ainsi des protocoles par certification, La vérification des conflits
(sérialisabilité) à la phase de validation d’une transaction c'est-à-dire à la fin
d’exécution, le choix de détection du conflit au plus tard est argumenté sur la base
que l’existence des conflits est rare.
La validation de cette transaction sera réalisée si aucun conflit n’a été détecté
sinon le traitement dépendra selon le protocole optimiste mis en œuvre.
D’après [KUG 81] lorsqu’une transaction arrive à son terme, le test pour
détecter les conflits se fait en deux principales stratégies :
La certification en avant : c’est la vérification de la transaction par rapport aux
transactions en cours.
La certification en arrière : c’est la vérification de la transaction par rapport
des transactions récemment validées.
Ce type de protocole exécute une séquence de trois phases :
39
Lecture
Certificatio
n
Ecriture
Figure II.5 Les phases d’exécution des protocoles par certification [KUG 81]
La première phase (Lecture) : consiste de faire une copie de données dans

l’espace de travail de la transaction, les mises sont enregistrées dans un fichier
temporaire.
La deuxième phase (Certification) : concerne de tester la transaction par

rapport certain transactions selon le type de certification, ce résultat de test indique
l’inexistence d’aucun conflit, la transaction passe à la dernière phase, dans le cas
contraire la transaction sera abandonnée ensuite redémarrée.
La troisième phase (Ecriture) : c’est d’appliquer les changements enregistrés
dans le fichier temporaire sur la base de données.
Le choix des méthodes optimistes se fait pour les transactions avec minimum
de conflit d’accès aux données, ce qui implique un nombre minimum de transactions
à abandonnées, par contre si le critère de nombre de conflit devient nombreux, alors
il est préférable d’utiliser les méthodes pessimistes.
II.6.2 Méthodes pessimistes (contrôle continu):
Contrairement aux protocoles optimistes, les protocoles pessimistes

cherchent à éviter les conflits de concurrences d’utilisation de la même granule par
un ensemble de transactions à l’avance, donc ces protocoles sont des protocoles
dites préventifs, un contrôle continu de l’exécution pour vérifier que le critère de
serialisabilité est vérifié [GAR 03].
40
Ce type de protocole est nommé pessimiste sur la base que dans le SGBD,
des conflits potentiels sont toujours possibles lors de l’accès simultané aux données
par plusieurs transactions. Ils imposent donc la pose de verrous sur les objets
auxquels accèdent les transactions.
En réalité, La majorité des SGBD utilisent les méthodes pessimistes.

Il existe plusieurs protocoles de gestion de concurrence, on site :
II.7 Le verrouillage à deux phases :
Le protocole de verrouillage à deux phases (en anglais Two-Phase

Locking), est un protocole pessimiste qui utilise le principe de verrouillage pour
éviter les conflits [GAR 03], le principe de ces méthodes dans chaque transaction
doit verrouiller le granule désiré.
Le granule représente l’unité de verrouillage, il peut intervenir à différents
niveaux de la base de niveau supérieur au niveau bas, le granule peut concerner la
base de données en totalité comme il peut concerner une relation , une page de
données, une ligne d’une relation ou une partie de cette dernière avec une
surcharge qui peut être supérieure au gain de performance.
La méthode 2PL exécute deux phases :
La phase d’expansion qui sert à l’acquisition au fur et à mesure des verrous

sans faire libérer aucun.
La phase rétrécissement concerne la libération des verrous et plus aucune

autre acquisition de verrous. Cette phase est exécutée quand la transaction
se termine par commit ou rollback.
Il existe deux types de verrou :
Le verrou partagé (Shared Lock) : utilisés pour verrouiller un granule

partageable en lecture par plusieurs transactions concurrentes.
Le verrou exclusif (Exclusive Lock) : est utilisé pour affecter le droit

d’utilisation du granule uniquement à une seule transaction en mode écriture,
ce qui implique que si une donnée est verrouillée en écriture, aucun autre
verrou ne peut être posé pour une transaction tant que ce verrou n’a pas été
libéré.
41
Le protocole décide d’attribuer le droit d’utilisation d’un granule à une

transaction qui fait la demande selon la matrice de compatibilité de données.
Verrou détenu
S X -
Verrou demandé
S Autorisée Non Autorisée Autorisée
X Non autorisée Non autorisée Autorisée
Tableau II.1 Matrice de compatibilité des verrous [GAR 03]
Le verrouillage des granules se fait automatiquement par le SGBD, mais

certains SGBD donnent aux utilisateurs la main de verrouiller certains granule.
L’un des avantages de ce protocole est sa facilité l’implémentation. C’est la

raison principale de sa large utilisation. Un autre avantage est qu’il permet de
conserver l’exclusivité d’un objet aussi longtemps que nécessaire [GAR 03].
Le protocole de verrouillage à 2 phases garantit la propriété de sérialisabilité

mais présente également des inconvénients non négligeables, il s’agit des
problèmes l’interblocage et famine.
II.7.1 La notion d'interblocage :
Le problème d’interblocage (verrous mortels en anglais deadlock),

l’interblocage peut être direct ou indirect, ce problème survient lorsqu’une transaction
T1 demande et obtient le granule G1 en écriture. La transaction T2 demande ensuite
et obtient le granule G2 en écriture.
Si T1 demande ultérieurement le granule G2 sans avoir libéré le granule G1, il
est bloqué en attendant la libération par T2. Si maintenant, T2 demande le granule G1
avant de libérer le granule G1, il est bloqué en attendant la libération par T1 de ce
granule.
On voit que chacune des transactions est bloquée, en attendant que l'autre
libère le granule qu'il possède. On dit qu'il y a un interblocage entre les transactions.
42
T1 T2
G1 G2
Figure II.6 Schéma d’interblocage [BUC 05]
En fait, tout interblocage est signalé par la présence d'un tel cycle entre les
transactions et les granules.
Le problème de l'interblocage est résolu selon :
La méthode de détection : elle consiste à vérifier périodiquement la présence

de tels cycles, en cas de présence de cycle alors :
Faire tuer une transaction.

Défaire ses actions.
Libérer ses ressources correspondantes.
La méthode de prévention : elle consiste à imposer aux transactions

d’acquérir en avance l’ensemble des verrous sur les granules demandés, ainsi une
transaction n’a pas le droit de verrouiller un sous ensemble de granule en attente de
libération des autres, ce qui implique que des transactions de telle sorte qu'un tel
cycle ne puisse jamais se produire.
Si deux transactions demandent leurs verrous dans le même ordre, la

deuxième transaction serait bloquée sur la demande de premier granule, sans avoir
encore obtenu aucun verrou, et il ne pourrait y avoir de cycle.
II.7.2 La notion de famine :
Ce problème apparaitra quand une transaction est maintenue indéfiniment dans

un état d’attente sans être pour autant en situation d’interblocage, On dit que l'on a
une situation de famine (en anglais starvation). Lorsqu’un verrou est relâché sur un
granule G, [GAR 84] l’algorithme d’attente par priorité des utilisateurs choisit parmi
les transactions existante dans la file d’attente, la plus prioritaire, donc ce type
43
d’algorithme défavorise les transactions moins prioritaire, pour remédier à ce

problème on utilise un autre critère d’attribution de priorité selon (FIFO) l’ordre
d’entée dans la file (Date de la demande de la ressource).
Plusieurs variantes du protocole 2PL ont été proposées pour améliorer les
performances des systèmes de gestion des bases de données.
II.8 Méthodes par estampillage :

Le mécanisme de gestion des concurrences par verrouillage à deux phases
détecte à posteriori des attentes entre transactions. Des mécanismes de prévention
basés sur un ordonnancement à priori des actions composantes des transactions
peuvent être aussi envisagés.
Les méthodes par estampillage représentent des méthodes préventives, qui

sont des protocoles garantissant aussi la sérialisation.
La méthode par estampillage est basée sur l’attribution de l’ordonnanceur d’un

identifiant représenté par numéro d’ordre cacheté sur la transaction au moment de
son démarrage, ce numéro est génère soit à partir de l’horloge système où le
numéro reçoit l’heure de déclenchement de la transaction ou bien un numéro
séquentiel [GAR 03].
L’utilisation des estampilles pour le but d’exécuter les transactions dans une
planification sérielle équivalente.
Avec les méthodes par estampillage il n’y a aucune attente car lorsque des
transactions rentrent en conflit d’accès à un granule dans un mode incompatible, la
transaction vainqueur est la transaction de la plus petite estampille (la plus
ancienne), les autres transactions seront annulées et le redémarré de nouveau pour
pour avoir des nouveaux numéros.
Si une transaction demande l’accès à un granule libre et cette demande

concerne une transaction avec numéro d’ordre supérieur au numéro noté par le
granule alors la transaction détient le granule sinon la transaction est annulée, et
redémarrée pour que la transaction aura un numéro plus grand.
Le protocole par estampillage a comme avantage l’absence de problème de

blocage, mais le problème de famine reste car une transaction peut être bloquée
44
infiniment ainsi on peut avoir le problème d’abandon en cascade c'est-à-dire

annulation d’une transaction G engendrant l’abandon de l’ensemble des transactions
ayant utilisées les résultats de mises à jour de la transaction G.
Pour les méthodes par estampillage il existe deux types d’ordonnancement,

l’ordonnancement total et l’ordonnancement partiel.
II.8.1 Ordonnancement total :
Chaque granule garde l’estampillage de la dernière transaction, lorsqu'une

transaction veut effectuer une action sur un granule, elle appelle une procédure
d'accès qui lui donne ou non l'autorisation.
Soit E(Ti) l’estampillage de la transaction i et E(G) l’estampillage de granule G

le granule de la transaction Ti et E(G).
La procédure est simple, selon le résultat de comparaison entre l'estampille de

la transaction demandeur avec l’estampillage du granule. Si l’estampillage de la
transaction est supérieur ou égale alors la transaction a le droit d’utilisation dans le
cas contraire on annule la transaction.
L’accès au granule donné se fait selon cet algorithme :
Procédure d’Accès
Si E(Ti) >= E(G)
Alors
Autoriser l’accès ;
E(g) := E(Ti) ;
Sinon
Figure II.7 Algorithme d’ordonnancement total pour l’accès à un granule [DON 02]
II.8.2 Ordonnancement partiel :
Représente une amélioration de l’ordonnancement total, pour cette catégorie

chaque granule garde la trace de la dernière estampille de lecture concernant le
45
numéro d’ordre de la dernière transaction ayant consulté le granule, et une autre

estampille de mises à jours indiquant la dernière transaction qui a effectuée une
écriture sur ce granule.
L’ordonnanceur partiel est doté de deux procédures pour la gestion des accès
aux données, la première concerne le droit en lecture, et la deuxième pour l’écriture.
Soit les propriétés suivantes :

EL(G) : Représente l’estampille en lecture du granule G.
EE(G) : Représente l’estampille d’écriture de granule G.
Pour utiliser un granule en lecture selon l’ordonnancement partiel :
Procédure de lecture
Si EE(G) ≤E(Ti) alors
Lire (G) ;
EL(G) : = Max (EL(G), E(Ti) ) ;
Sinon Rollback ;
Finsi ;
Figure II.8 Algorithme d’ordonnancement partiel pour l’accès en lecture à un granule [DON 02]
Pour utiliser un granule en lecture selon l’ordonnancement partiel :
Procédure d’écriture
Si (EL(G) ≤E(Ti)) et (EE(G) ≤E(Ti)) alors
Ècrire (G);
EE (G): =E (Ti) I ;
Sinon Rollback;
Finsi ;
46
Figure II.9 Algorithme d’ordonnancement partiel pour l’accès en écriture à un granule [DON 02]
II.9 Conclusion :
Le volume important de données est difficile à gérer par le système de gestion

des fichiers, pour cela les systèmes de gestion des bases de données garantissent
une meilleure performance, soit au niveau de gain de volume ou au niveau de
sécurité de données.
Le système de gestion des bases de données garantissent la validité de
l’information selon certaines contraintes d’intégrités (check, primary foreign ou
unique).
Le SGBD garantit que la validation d’une transaction engendre le passage de

la base d’un état cohérent vers un autre état cohérent.
L’exécution en concurrence de données par plusieurs transactions peut

produire trois principaux problèmes la perte de mise à jour, la lecture impropre, la
lecture non reproductible, pour cela le SGBD est doté d’un ordonnanceur qui planifier
l'ordre dans lequel les opérations des transactions concurrentes sont exécutées.
L'ordre d'exécution des transactions est critique. Cet ordre doit assurer
l'intégrité de la base de données dans un système de base de données multi
utilisateurs.
Plusieurs mécanismes de gestion de concurrences on été développés qu’on

les classes en deux familles, les protocoles pessimistes et optimistes, dans la
majorité des SGBD commerciaux utilise la première famille.
Un système temps réel manipule des données classiques comme il manipule

des données avec des contraintes temporelles, les SGBD classiques ne peuvent
pas garantir le respect des contraintes temporelles, ce qui à permis de donner une
naissance pour les Système de gestion des bases de données temps réel
(SGBDTR).
47
CHAPITRE III
SYSTÈME DE GESTION
DE
BASES DE DONNÉES
TEMPS REEL
CONCLUSION GENERALE
III.1 Introduction :
Un STR est un système dont le comportement dépend non seulement de

l’exactitude des traitements effectués (L’objectif des systèmes classiques), mais
également du temps où les résultats de ces traitements sont fournis [10]. Un STR
doit être conçu tel que ses performances seraient définies dans le pire des cas, et
savoir à l’avance si un système va respecter ses contraintes temporelles. Mais ils ne
sont pas satisfaisants pour la gestion efficace des données lorsque celles-ci sont
volumineuses, et seul un système de type SGBD pourrait répondre à ce besoin
[MAM85].
Les SGBD classiques ne tiendront pas en compte l’échéance des données, car
ils n’intègrent pas des mécanismes qui permettent de prendre en compte les
contraintes temporelles. Ceci implique la nécessité d’avoir des systèmes de
gestion de base de données temps réel [RAM93a]. Un système de gestion de base
de données temps réel peut être vu comme un amalgame d'un système temps réel
et un système de gestion de base de données classique.
Ce chapitre présentera les caractéristiques des systèmes de gestion de bases
de données temps réel.
III.2. DONNEES TEMPS REEL :
La plupart des applications temps réel ont besoin de stocker et manipuler des
volumes importants d’informations qui proviennent de l’environnement contrôlé par le
système. Ces données peuvent être textuelles comme la position numérique des
objets ou multimédia comme la position graphique des objets captée par les caméras
de surveillance, ce qui indique que dans les SGBDTR, les données représentent la
capture de l´état du monde réel.
Le nombre d’entité d’une base de données temps réel varié selon l’application
temps réel relative. Le tableau suivant représente cette différence.
49
CONCLUSION GENERALE
Application Nombre d’entité
Mission aérienne 3000
Surveillance du trafic aérien 20000
Contrôle industriel 100000
Tableau III.1 : Nombre d’entités manipulées de certaines applications temps réel [LOK 01]
Les données doivent être remises à jour régulièrement afin de refléter au

plus près le monde réel. Ceci permet de dire que les données manipulées par les
applications temps réel sont des données temps réel, c'est-à-dire que ces dernières
sont utiles seulement si elles sont utilisables et utilisées dans le temps. Ce qui
désigne que ces données sont caractérisées par la durée de validité. Ceci implique
que les données deviennent non actualisées une fois que la borne supérieure de
l’intervalle est dépassée sans qu’elles ne soient mises à jour.
Les systèmes de gestion de bases de données temps réel utilisent des

données classiques et des données temporelles. Les données temporelles sont
caractérisées par une durée de validité. Les données temps réel doivent refléter le
réel. Pour ce type de données, on trouve des données de bases qui sont issues de
capteurs et reflètent l’état de procédé. Les données de bases servent à calculer les
données dérivées qu’elles permettent de déduire des informations sur
l’environnement étudié. A titre d’exemple la vitesse est calculée à la base de la
distance parcourue ainsi que durée du parcours[HUO 04].
La durée de validité d’une donnée dérivée est calculée à la base de toutes les
durées de ces composants.
Le schéma suivant résume les types de données manipulées par les

systèmes de gestion de bases de données.
50
CONCLUSION GENERALE
Figure III.1 : Les types de données manipulés par les SGBDTR [DIP 95]
Les conséquences résultant de l’accès d’une transaction à une donnée en

dehors de sa durée de validité dépendent des besoins particuliers de l’application et
de la sémantique des données. Les applications temps réel manipulent également
[SCH 98]:
Les données actives : Ce sont des données dont la mise à jour

déclenche une réaction du système qui se matérialise par l’envoi d’un ou plusieurs
ordres d’exécution d’opérations comme les mises à jour d’autres données,
déclenchement d’une alarme …etc.
Les données temporelles : Ce sont des données datées, qui

permettent de gérer l’historique de leur évolution.
La durabilité d’une entité diffère d’une application à une autre. Le tableau suivant
représente la durabilité de quelque application.
51
CONCLUSION GENERALE
Application Durabilité
Mission aérienne 4 heures
Surveillance du trafic aérien 12 heures
Contrôle industriel 5 jours
Tableau III.2 : La durabilité des entités de certaines applications temps réel [LOK 01]
III.3 Formalisation de la cohérence :
Le maintien de la cohérence des données représente l’un des problèmes de

la conception de SGBD temps réel [XIO 96], ce qui doit garantir une équivalence
entre l’environnement tel qu’il est perçu par le système contrôleur et l’état réel de cet
environnement. Cette obligation a une conséquence sur la conception de SGBD
temps réel, qui doit respecter en plus des contraintes d’intégrité (cohérence logique)
les contraintes de cohérence temporelle des données.
On dit que la donnée d est dans un état correct, si et seulement si :
1) La valeur de cette donnée est logiquement cohérente, c’est-à-dire elle

satisfait les contraintes d’intégrité décrites dans la phase description.
2) d est temporellement cohérente. Cette contrainte regroupe deux notions

[SON 92] :
La cohérence absolue qui est liée directement au fait que l’image de

l’environnement dans le système doit refléter l’état réel de cet environnement. Cette
cohérence est nommée ainsi par la cohérence externe.
La cohérence relative qui est liée aux données utilisées pour dériver
d’autres données dans la base et qui doivent être cohérentes entre elles.
Pour illustrer ces deux notions, reprenons la définition d’une donnée temps
réel d proposée dans [RAM 93] : d = (dvaleur, destampille, ddva), où dvaleur est la valeur
actuelle de la donnée d. destampille représente l’instant où cette valeur a été mesurée
ou calculée et ddva est la durée de validité absolue de la valeur d.
Un ensemble de cohérence relative R est l’ensemble des données utilisées

pour dériver une nouvelle donnée. À tout ensemble R est associée à une durée de
52
CONCLUSION GENERALE
validité relative Rdvr. Soit d ∈ R. On dit que d est dans un état correct, si et seulement
si :
1) dvaleur est logiquement cohérente.
2) d est temporellement cohérente si et seulement si elle a une:
Cohérence absolue : (instant_courant - destampille) ≤ ddva
cohérence relative : pour tout d’∈ R, | destampille – d’estampille | ≤ Rdvr.
Exemple :
Soit la contrainte d’intégrité suivante :

Valeur de la température >200.
A l’instant t=100 les capteurs envoient les informations suivantes :
Valeur de la température est 260. Cette valeur respecte la contrainte d’intégrité

et la valeur de la pression =73
Température dva = 5, pression dva = 10
L’ensemble de validité relative R = température, pression Soit Rdvr = 2 alors :
a) température = (valeur, dva, estampille) = (260, 5, 95) et pression =(73,

10, 97) sont cohérentes temporellement car :
Absolue car |100-95| ≤ 5 et |100-97| ≤ 10

Relative car |95-97| ≤ 2
b) température = (260, 5, 95) et pression = (73, 10, 92) ne sont pas

cohérentes temporellement car :
Absolue : est vérifiée car |100-95| ≤ 5 et |100-92| ≤ 10

Relative : non n’est vérifiée car |95 - 92| = 3 > Rdvr = 2 ce qui implique
que les valeurs de la température et de la pression ne sont pas saisies.
Les valeurs de la cohérence absolue et de la cohérence relative sont très

différentes selon l’application. Le tableau suivant présente la valeur de ces deux
paramètres pour quelque application :
53
CONCLUSION GENERALE
application Cohérence absolue Cohérence relative
Mission aérienne 0.05 S 0.02 S
Surveillance du trafic aérien 1.5 S 3S
Contrôle industriel 0.2 S 0.5 S
Tableau III.3 : Les caractéristiques de cohérence de certaines BDDTR [LOK 01]
III.4 Les propriétés ACID des transactions temps réel :
Pour réaliser un SGBDTR, plusieurs travaux réalisés sur les SGBD classiques
peuvent être exploités. La conception des SGBDTR doit prendre en compte que les
transactions s’exécutent avant leurs échéances. Ces transactions accèdent aux
données avant une validité limitée [PUR 94].
Le respect de l’échéance est souvent plus important que la précision de résultat,

ce qui signifie qu’un résultat partiel qui respecte l’échéance est parfois plus utile
qu’une réponse complète qui arrive en retard. Ceci permet de dire que certaines
actions de la transaction partielle peuvent être annulées si leur échéance est
dépassée, et confirme que la propriété d’atomicité des transactions n’est pas toujours
vérifiée .
La notion de durabilité dans les SGBDTR est différente dans les SGBD
classique, car dans ces derniers, dés la validation des transaction de mise à jour le
nouveau contenu de la BDD devient permanent. Par contre, dans les SGBDTR et
particulièrement ce qui touche les données acquises par les capteurs, les
modifications se réalisent périodiquement ce qui implique que la persistance de
données est assurée que durant leur durée de validité.
La notion de sériabilité dans les SGBDTR est similaire a ceux dans les SGBD
classiques sauf qu’on ajoute des contraintes temporelles.
III.5 Classement des transactions temps réel :
Les transactions temps réel sont classées selon deux critères :
III.5.1. Classement des transactions temps réel selon type d’objet:
Les transactions temps réel manipulent des données de base acquises à

partir de l’environnement comme la position et la vitesse d’un missile ennemi, ou des
54
CONCLUSION GENERALE
objets dérivés calculés à partir d’autres objets comme le calcul de la vitesse et le

degré de rotation de l’antimissile.
Selon ces deux types de données, les transactions sont classées [XIO 96] :
Transactions sensorielles : Ceux sont des transactions en écriture seule,

concernant la mise à jour des données de base.
Transactions déclenchées de mise à jour : Ceux sont des transactions

composées des opérations de lecture et des opérations d’écriture. Elle concernent
les objets dérivés. Ce type de transaction est déclenché après la mise à jour de ces
objets de base.
Transactions utilisateur : Ceux sont des transactions déclenchées par

l’utilisateur, avec des échéances. Elles sont en lecture/écriture.
III.5.2. Classement des transactions temps réel selon l’échéance:
Les transactions en temps réel doivent respecter l’échéance. Dans le cas de

non respect de l’échéance, la transaction sera annulée et l’effet de cette annulation
sera sur le système et l’environnement. Les transactions dans un SGBDTR sont
classées en trois catégories [Ram 93].
Transactions à échéances strictes et critiques : (hard deadline

transactions) : Sont appliquées pour les systèmes critiques comme le systèmes de
contrôle des sites nucléaires.
On doit terminer l’exécution de ce type de transaction avant la fin de

son échéance pour éviter les catastrophes humaines et matérielles.
Valeur
Temps
Echéance
Figure III.2 : Echéance stricte et critique [SAD 04]
55
CONCLUSION GENERALE
Transactions à échéances strictes et non critiques (Firm Deadline

Transaction) : dans le cas d’une transaction qui dépasse son échéance, elle
devient inutile pour le système et sans aucune conséquence importante. Les
transactions de cette catégorie sont abandonnées. Exemple du robot qui
capte des informations sur des objets défilant sur un convoyeur. Si l’opération
d’acquisition n’est pas achevée avant la disparition de l’objet du champ de
vision du robot, elle est abandonnée et redémarrée pour prendre en compte le
prochain objet. Le même principe pour les transactions boursières.
Valeur
Echéance Temps
Figure III.3 : Echéance stricte non critique [SAD 04]
Transactions à échéances non strictes (soft deadline transactions) : dans

le cas d’une transaction qui arrive après son échéance, le système ne l’abandonne
pas immédiatement car cette transaction peut avoir temporairement une certaine
utilité, mais la qualité de service qu’elle offre est moindre, l’exemple de la
synchronisation image et son pour les systèmes multimédia. Pour ces système on
accepte un certain seuil de désynchronisations entre image et son.
Valeur
Temps
Echéance
Figure III.3 : Echéance non stricte [SAD 04]
56
CONCLUSION GENERALE
Une transaction est composée d’un ensemble d’opérations de lecture et

écriture. La durée d’exécution de ces deux opération est bornée. Le tableau suivant
donne un aperçu de ces bornes pour quelques applications temps réel.
Application Durée minimale d’une Durée maximale d’une

lecture écriture
Mission aérienne 0.05ms 0.02S
Surveillance du trafic aérien 0.05 ms 3S
Contrôle industriel 1ms 0.5 S
Tableau III.4 : Les caractéristiques de cohérence de certaines BDDTR [LOK 01]
Les SGBDTR doivent garantir l’exécution avec validation des transactions à

échéances strictes et critiques sans dépasser de délais, pour réduire au maximum le
nombre de transactions qui ratent leurs échéances concernant les deux autres
catégories de transactions (transactions à échéances strictes et non critiques ou à
échéances non strictes). Pour ces deux types existe plusieurs travaux concernant
particulièrement les techniques de contrôle de concurrence et l’ordonnancement des
transactions. Par contre, pour les transactions à échéances strictes et critiques, on
ne trouve pas des algorithmes d’ordonnancement des transactions qui arrivera leurs
objectifs dû à l’indéterminisme de ces transactions et l’absence de méthodes
permettant d’estimer avec précision le temps d’exécution des transactions.
III.6 Qualité de service :
Dans les systèmes de gestion de base de données, le critère de performance

est caractérisé par le temps de réponse moyen d’exécution des transactions. Par
contre pour les systèmes de gestion de base de données temps réel , où on doit
respecter les échéances des transactions, le critère de performance est représenté
par la règle suivante [AMI 03] :
é
MR=100∗

57
CONCLUSION GENERALE
Ce critère présente le nombre des transactions qui ont ratées leurs échéances
divisé sur le nombre total des transactions, le SGBDTR doit minimiser au maximum
cette métrique.
III.7. Marché des SGBDTR :
Aucun SGBDTR n’est commercialisé. On trouve seulement des simulateurs

destinés pour des objectifs bien déterminés par exemple :
Le simulateur RADEx destiné pour la simulation des contrôle de

concurrence et ordonnancement des transactions temps réel.
Trafca : est un système de base de données temps réel destiné au
contrôle aérien.
III.8 Conclusion :
Les systèmes de gestion de base de données assurent le respect des

contraintes d’intégrités logiques soient : les contrainte Check ou Foreign Key ou
Primary Key. Mais les contraintes temporelles concernant le type de données
temporelle ne sont pas assurées par ce type de système, pour cela plusieurs
travaux de conception ont été réalisés.
Les système de gestion de base de données classiques assure l’exactitude de

données sans aucune limitation de temps d’exécution de la transaction,
contrairement aux systèmes de gestion de bases de données temps réel, où chaque
transaction est paramétrée par une durée d’exécution, selon le type de la transaction
temps réel dur ou souple que le SGBDTR décide d’abandonner ou de continuer
l’exécution de la transaction.
Le but des systèmes de gestion de base de données temps réel est de

minimiser le nombre de transactions qui ratent leurs échéance concernant le type de
transaction non stricte et de satisfaire l’exécution des transactions strictes. Pour cela,
le système de gestion de base de données doit combiner les protocoles
d’ordonnancement appliquées dans les systèmes temps réel et les méthodes de
gestion des concurrences manipulées par les systèmes de gestion de base de
données classiques.Le chapitre suivant présentera les différents travaux réalisés
pour l’ordonnancement et gestion de concurrence dans les systèmes de gestion de
base de données temps réel.
58
CHAPITRE IV
PROTOCOLES
D’ORDONNANCEMENT ET
CONTRÔLE DE
CONCURRENCES
CHAPITRE IV PROTOCOLES D’ORDONNANCEMENT ET CONTRÔLE DE CONCURRENCES
IV.1 Introduction :
Dans les systèmes de gestion de base de données classiques,

l’ordonnancement sérialisable des transactions représente une solution qui permet
de garantir le contrôle de concurrence d’accès aux données. Par contre, pour les
bases de données temps réel, certains ordonnancements sérialisables sont rejetés
pour ceux qui ne respectent pas leurs échéances. Ceci implique que les protocoles
de contrôle de concurrence développés pour les systèmes de gestion de base de
données ne sont pas appliqués directement pour les systèmes de gestion de base
de données temps réel.
Les SGBD classiques garantissent le maintien uniquement de la cohérence

logique. Par contre, dans une base de données temps réel, il est nécessaire de
respecter la cohérence temporelle.
Les travaux réalisés sur le contrôle de concurrence des transactions dans les
SGBDTR s’appuient sur les techniques de contrôle de concurrence appliquées dans
les SGBD classiques et sur les techniques d’ordonnancement des tâches dans les
systèmes temps réel.
Ce chapitre présentera les différents travaux développés dans ce contexte.
IV.2 Les protocoles d’ordonnancement et contrôle de concurrence
Un protocole de contrôle de concurrence sert à éviter les risques d’incohérence

dans la base de données en cas deux ou plusieurs transactions désirent accéder au
même granule en mode incompatible (Lecture/Ecriture, Ecriture/Lecture,
Ecriture/Ecriture).
Les travaux réalisés dans ce domaine pour les systèmes de gestion de base de
données temps réel se basent sur les mêmes types de protocoles utilisés dans les
systèmes de gestion de base de données classiques qui sont : les protocoles
optimistes et les protocoles pessimistes.
IV.2.1 Techniques optimistes :
Les techniques optimistes sont des protocoles par certification. pour les
SGBDTR, ces protocole ont le même principe que pour les SGBD classiques où
60
l’une des transactions en conflit avec d’autres sera abandonnée et redémarrée

selon certaines hypothèses pour éviter les incohérences dans la base.
Pour ce type de protocole de contrôle de concurrence, la vérification de

l’existence des conflits se fait au moment de la phase de validation (méthode de
certification), se basant sur l’hypothèse qu’il existe une faible probabilité pour que
deux transactions rentrent en concurrence sur un même granule de donnée.
D’après [KUN 81] lorsqu’une transaction arrive à son terme, le test pour détecter les
conflits se fait en deux principales stratégies :
La certification en avant : c’est la vérification de la transaction par rapport

aux transactions en cours, en cas l’existence des objets en commun avec
d’autres transactions, alors une erreur de sérialisation est détectée ce qui
engendre de maintien d’une transaction au choix et d’abandonner les autres
transactions.
La certification en arrière : c’est la vérification de la transaction par rapport

aux transactions récemment validées. Si l’un des objets manipulés par la
transaction est en conflit avec une transaction validé alors la transaction en
cours sera abandonnée car cette dernière pourrait ne pas avoir pris
connaissance de la nouvelle valeur de l’objet.
Exemples de protocoles de contrôle de concurrence optimistes :
IV.2.1.1 OCC-BC (Optimistic Concurrency Control-Broadcast

Commit):
C’est une variante algorithme OCC de base [MEN 82]. C’est une méthode avec
certification en avant, qui a pour but de redémarrer les transactions le plus tôt
possible.
Le principe de cet algorithme consiste à ce que la transaction qui effectue une

validation avertisse l’ensemble des transactions en conflit avec elle au cours de sa
validation, pour qu’elles redémarrent immédiatement. Ceci augmente leurs chances
de terminer avant la fin de leurs échéances.
IV.2.1.2 Protocole OCC-BC- OPT-Sacrifice

C’est un protocole temps réel dérivé du protocole OCC-BC [HAR 92], ce
protocole prend en considération l’ordre des priorités des transactions.
61
Considérons une transaction Tc en phase de validation et si avant sa validation,

cette transaction entre en conflit avec d’autres transactions Ti (i :=1…….n) deux cas
peuvent se présenter :
Si La priorité de Tc > La priorité des autres transactions (Ti…Tn)

Alors
Abandonner les Ti.
Sinon
S’il existe une ou plusieurs transactions Tk avec priorité (Tk) > priorité
(Tc) alors
Abandonner et redémarrer Tc (elle se sacrifie).
Fin Si
Figure IV.1 Algorithme OCC-BC-OPT-Sacrifice [HAR 92]
Ce protocole favorise les transactions les plus prioritaires. Le cas qui se pose
est qu’une transaction se sacrifier pour une transaction plus prioritaire, et que cette
dernière sera annulée plus tard à cause du dépassement d’échéance.
IV.2.1.3 Protocole OCC-BC- OPT-WAIT :
C’est un protocole temps réel dérivé du protocole OCC-BC, développé pour

remédier au problème des sacrifices inutiles.
Le principe de ce protocole est qu’une transaction Tc en phase de validation, et

si avant de sa validation, cette transaction entre en conflit avec d’autres transactions
Ti (i :=1…….n) alors

Alors
Abandonner les Ti.
Sinon
S’il existe une ou plusieurs transactions Tk avec priorité (Tk) > priorité
(Tc) alors
Mettre en attente Tc.
Fin Si
Figure IV.2 Algorithme OCC-BC-OPT-WAIT [HAR 92]
Cet algorithme favorise les transactions prioritaires pour validation. Dans le cas où
une transaction prioritaire est validée alors l’ensemble des transactions en conflit avec la
transaction Tc seront abandonnées et redémarrées. Par contre, une transaction en
62
attente peut être validé si l’ensemble des transactions plus prioritaires et concurrente à
elles ont dépassées leurs échéances.
IV.2.1.4 Protocole OCC-BC- OPT-WAIT-50 :
C’est une méthode variante de protocole OPT-WAIT [HAR 92] . En plus de

l’attente, ce protocole est doté d’un mécanisme de contrôle de l’attente.

Alors
Abandonner les Ti.
Sinon
Attente de Tc jusqu'à ce que 50% des conflits soit résolus
Redémarrer les Ti restantes.
Fin Si
Figure IV.3 Algorithme OCC-BC-OPT-WAIT-50 [HAR 92]
La modification de cet algorithme par rapport d’OCC-BC-OPT-WAIT est

effectuée au niveau du cas 2. En fait dans ce cas, Tc doit attendre jusqu’à ce que
seulement moins de 50% des transactions avec lesquelles elle est en conflit aient
des priorités supérieures à la sienne. Une fois le seuil est atteint, alors les Ti
restantes sont abandonnées sans tenir compte de leurs priorités et la transaction Tc
réalise sa validation.
IV.2.1.5 Protocole CCA :
Le protocole CCA (Cost Conscious Approach) [HON 93], est développé pour
améliorer les performances des deux premiers protocoles conçus pour
l’ordonnancement des transactions temps réel.
EDF-HP (Earliest Deadline First-High Priority) [ABB 88], est un protocole
d’ordonnancement des transactions temps réel. Son principe est d’attribuer la
priorité supérieure à la transaction ayant la plus proche échéance.
L’inconvénient de cet algorithme est que certaines transactions moins

prioritaires en phase de validation sont abandonnées alors qu’elles puissent terminer
63
leurs exécutions sans aucunes influences sur les transactions de priorités

supérieures.
EDF-CR (Earliest Deadline First -Conditional Restart) [ABB 88], représente

une amélioration de protocole EDF-HP. Cet algorithme utilise une autre information
supplémentaire c’est l’estimation du temps restant pour achever l’exécution des
transactions . Ce qui permet aux transactions non prioritaires de se terminer à
condition que cela ne conduise pas les autres transactions de haute priorité de rater
leurs échéances.
Le protocole CCA représente une extension de protocole EDF-CR, qui

prend en compte non seulement les aspects statiques de l’exécution des
transactions mais aussi les aspects dynamiques.
La priorité des transactions est dynamique. Elle change au cours d’exécution.

Le principe de base de protocole CCA est la Pré-analyse des transactions ce
qui permet d’avoir une connaissance sur les données à accédées en fonction des
chemins d'exécution.
L’analyse du coût des annulations de transaction est une information inclue
dans CCA pour le calcul des priorités, ce qui permet de minimiser le nombre de
transactions à abandonnées.
Le protocole CCA d’après les simulations réalisées [CHA 98] montre que cette
méthode est plus adaptative que les deux autres.
IV.2.2 Techniques pessimistes:
Sont dite ainsi des protocoles bloquantes, pour les SGBDTR ces protocole ont
le même principe que pour le protocole SGBD classiques où utilisent la notion de
verrou pour empêcher l’accès incompatible aux données par les transactions, c’est-
à-dire c’est la transaction T1 demande un verrou sur un granule de donnée détenu
par T2 alors T1 est bloqué jusqu'à la libération du verrou sur le granule de donnée
par T2.
L’utilisation de 2PL dans les SGBDTR n’atteint pas l’objectif, car on peut avoir
le problème d’inversion de priorité c’est-à-dire une transaction T1 de haute priorité
bloquée à cause du détient d’un granule de données par une transaction T2 moins
prioritaire [LIU 73].Ce problème a donné naissance à des protocoles variant de 2PL
64
adaptés pour les SGBDTR. Ces protocoles tiennent en compte la priorité des
transactions.
Les protocoles développés se basent sur l’héritage et l’abandon des priorités.
IV.2.2.1 Protocole 2PL-HP
2PL-HP (Two-Phase Locking-High Priority) est un protocole de type abandon

par priorité [HAR 92] . Cet algorithme abandonne les transactions les moins
prioritaires lorsque le problème d’inversion de priorité survient, ce qui permet
d’assurer la continuité d’exécution des transactions de hautes priorités ce qui
garantirait l’exécution des transactions urgente.
Dans le cas d’une transaction moins prioritaire qui désire d’avoir l’accès à un
granule de donnée verrouillé par une transaction plus prioritaire, l’algorithme 2PL-HP
utilise l’algorithme 2Pl classique.
L’inconvénient est que des transactions peuvent être abandonnées à cause

d’une transaction plus prioritaire et cette dernière peut ne se pas terminer avant son
échéance, ce qui engendre une baisse de performance du système [SAD 04].
IV.2.2.2 Protocole 2PL-WP

2PL-WP (Two Phase Locking Wait Promote) est un protocole de type
héritage de Priorité (ou de promotion de priorité). C’est un variant de 2PL classique.
Lors de l’apparition de problème d’inversion, cet algorithme affecte une
nouvelle priorité à la transaction détentrice de verrou. Cette priorité est promue au
même niveau que celle de la transaction demandeuse de verrou, jusqu’à ce qu’elle
termine et libère le verrou.
Soit Tdét la transaction détentrice de verrou et soit Tdem demandeuse de
verrou alors l’algorithme 2PL-WP est le suivant :
Si Priorité (Tdét) < priorité (Tdem)
Alors
Bloquer Tdem
Priorité (Tdét) := priorité (Tdem)
Sinon
Bloquer Tdem
Fin Si
Figure IV.4 Algorithme 2PL-WP [ABB 92]

65
Cet algorithme engendre deux problème : le premier est le temps de blocage

des transactions de hautes priorités qui reste imprévisible lorsque survient des
blocages en chaine, c’est-à-dire une transaction de haute priorité qui se bloque
plusieurs fois par des transactions moins prioritaires. Le deuxième problème est le
problème de ressources car les transactions moins prioritaires qui héritent de
priorités plus élevées entrent en concurrence avec les transaction de haute priorité
(Transactions critiques) , ce qui peut impliquer l’échec d’exécution des transactions
critiques (Manque d’échéance).
IV.2.2.3 Protocole Héritage conditionnel de priorité
C’est une variante de protocole d’héritage de priorité [HUA 90]. Son principe
est qu’une transaction de faible priorité n’hérite la priorité d’une autre transaction de
haute priorité que dans le cas où elle est proche de sa terminaison, sinon elle est
abandonnée. Donc, c’est un protocole qui autorise l’inversion de priorité mais avec
une durée limitée.
L’avantage est qu’il y a moins de travail perdu quand la transaction est loin de
sa terminaison, et les délais d’attente des transactions de hautes priorités sont
réduits.
Les simulations effectuées par Huang and Gruenwald [HUA 96] confirment les
bonnes performances de ce protocole par rapport aux protocoles d’héritage simple
et d’abandon par priorité
Si Priorité (Tdét) < priorité (Tdem)

Alors
Si temps restant (Tdét) <<<
Alors
Bloquer Tdem
Priorité (Tdét) := priorité (Tdem)
Sinon
Abandonner Tdét
Fin Si
Sinon
Bloquer Tdem
Fin Si
Figure V.5 Algorithme Héritage conditionnel de priorité [HUA 96]
66
IV.2.2.4 Protocole PCP (Priority Ceiling Protocol):
C’est le protocole de plafonnement de priorité, conçu au premier lieu pour

l’ordonnancement des taches temps réel [SHA 87]. Cet algorithme représente une
variante de protocole d’héritage de priorité. Cet algorithme permet d’éliminer
l’interblocage et autorise l’inversion de priorité avec pour une durée limitée.
Plusieurs adaptations de ce protocole aux systèmes de gestion de base de

données temps réel ont été effectuées. Le principe de base de ses protocoles est
d’extraire la priorité maximale d’une liste de transactions demandeuses d’acquisition
de verrou. La priorité extrait est attribuée au granule concerné.
Pour qu’une transaction détienne le verrou d’un granule de donnée, il faut que
la priorité de cette transaction soit supérieure à la priorité du granule de donnée
demandé.
IV.3 Conclusion :
Un système de gestion de bases de données temps réel doit satisfaire les

contraintes temporelle des transactions, ce qui n’est pas tenu en compte par les
systèmes de gestion de bases de données classiques. Pour cela, les SGBDTR
doivent utilisées des protocoles d’ordonnancement des transactions par l’attribution
des priorités aux transactions, ce qui permet de minimiser le nombre de transactions
qui ratent leurs échéance. Plusieurs protocoles d’ordonnancement ont été
développés dans ce domaine. L’attribution des priorités se fait à base de certaines
informations comme : l’échéance, le temps d’exécution restant …etc.
L’exécution concurrente des transactions pour l’accès aux granules de

données, peut engendrer la non satisfaction des échéances. Les SGBD classiques
utilisent des protocoles de contrôle de concurrence qui doivent être améliorés car
ses protocoles ne tiennent pas en compte l’échéance d’exécution des transactions.
Les travaux réalisés dans ce domaine sont basés soient sur les techniques de
redémarrage ou bien les techniques de blocage. La première technique engendre
comme problème l’annulation non utile de transactions. Par contre, la deuxième
approche cause le problème d’inversion de priorité. Après avoir entamer l’état de
l’art de ce mémoire, le prochain chapitre concerne la partie mise en œuvre du
simulateur de système de gestion de bases de données temps réel.
67
CHAPITRE V
IMPLÉMENTATION, TEST
ET
ÉVALUATION
CONCLUSION GENERALE
V.1 Introduction
Après avoir présenté l’état de l’art des systèmes de base de données temps
réel, où on a abordé les différentes caractéristiques des transactions et données
temps réel, et les protocoles de contrôle de concurrence des transactions existants,
on entame la deuxième phase objet de notre mémoire.
L’objectif de notre travail est de développer un simulateur des protocoles

d’ordonnancement et de contrôle de concurrence pour les SGBD Temps réel en
tenant compte des données de bases et dérivées.
Le simulateur à développer doit être paramétrable, autrement dit il permet à

l’utilisateur de définir de nouvelles valeurs concernant certains paramètres comme
le nombre de données temps réel à simuler.
Dans ce chapitre, on présente la conception et la mise en œuvre du simulateur à

développer ensuite son manuel d’utilisation et on le clôture par la présentation des
résultats des tests réalisés.
V.2 La simulation :
La simulation est une procédure permettant d’imiter et de simuler des phénomènes

réels afin de prédire le comportement de systèmes complexes [DEG 99].
La simulation permet l’évaluation des conséquences d’actions sans avoir à les mettre
en place réellement par le biais d’un programme informatique.
Les simulations informatiques sont devenues incontournables pour la modélisation

des systèmes naturels en physique, chimie et d’autre. Ici, la simulation permettra
d’appliquer certains protocoles d’ordonnancement et contrôle de concurrence
concernant les transactions temps réel.
V.3 Conception du simulateur :
Pour décrire le fonctionnement du simulateur à réalisé, on utilise un ensemble

d’outils techniques et on suit une méthodologie d’analyse et de conception bien
adapté.
Il existe plusieurs méthodes de conception. Nous avons choisi la méthode Unified

Modeling Langage UML.
69
CONCLUSION GENERALE
V.3.1 Présentation d’UML :

UML (Unified Modeling Langage), qu’on peut traduire par « langage de modélisation
unifié » est une notation permettant de modéliser un problème de façon standard.
UML offre une manière élégante pour représenter le système selon différentes vues
complémentaires grâce aux différents diagrammes. Chacun de ces diagrammes
correspond soit à la description d’une partie du système soit à la description du
système selon un point de vue particulier.
La méthode UML est souvent utilisée dans les conceptions car elle possède des
caractéristiques permettant une forte expression des éléments de conception [ROQ
07] :
Un langage sans ambigüité
Un langage universel pouvant servir de support pour tout langage
orienté objet.
Une présentation visuelle permettant la communication entre les acteurs
d’un même projet.
Une notation graphique simple, compréhensible même par des non
informaticiens.
Pour notre conception, on a utilisé les diagrammes d’UML 2.1 suivants :
Diagramme de cas d’utilisation
Diagramme de séquence
Diagramme de classe
V.3.2 Diagramme de cas d’utilisation :
Le diagramme de cas d’utilisation est destiné à représenter les besoins des

utilisateurs par rapport au système.
Le simulateur à réaliser doit tenir en compte les données dérivées si elles existent.
Mais avant de lancer une simulation on doit générer les transactions de mises à
jour.
Pour générer les transactions de mises à jour, on doit générer a priori la base de
données. Cette dernière dépend des paramètres définis par l’utilisateur.
SI la base de données contient des données dérivées on doit générer les

transactions de mises à jour de données dérivées.
70
CONCLUSION GENERALE
Une fois les données et les transactions sont générées, le simulateur simule selon
un contrôleur de concurrence spécifié par l’utilisateur.
Le simulateur doit afficher les différents états graphiques
V.3.2.1 Représentation graphique
Simulateur de SGBDTR
Générer les transactions de

données dérivées temps réel
Extended
Simuler
Utilisateur
En cas de données dérivées
Include
Specifier protocole CC
Include
Générer les transactions

temps réel
Include
Générer les données
Figure V.1 Diagramme cas d’utilisation générale du simulateur
71
CONCLUSION GENERALE
V.3.2.2 Description textuelle de cas d’utilisation générale du

simulateur
Rôle : appliquer les protocoles de contrôle de concurrence pour les transactions

temps réel
Version 1.0
Pré condition : /
Post condition: Existence de données temps réel
Scénarios
Nominatif
définir les paramètres de la base de données
Générer la base de données
Définir les paramètres de transaction temps réel
Générer les transactions temps réel
Spécifier le protocole de contrôle de concurrence (CC)
Simuler les transactions
Etablir les différents états graphiques
Alternatif
/
Exception :
Générer les transactions temps réel de données dérivées
V.3.2.3 Diagramme de classe
L’étude de la structure et du comportement des différentes classes du système,

nous a permis de définir les différents attributs ainsi que les différentes méthodes de
chaque classe.
Une classe concerne une entité. Chaque entité est caractérisée par un ensemble de
propriétés, des associations liées entre les classes. Le diagramme de classe de ce
simulateur est basé sur deux principales classes la classe données et la classe
transaction. La classe donnée contient les attributs en commun des données
classiques et données temporelles, cette dernière représente une super classe des
sous classes données temporelles de base et dérivées. La classe transaction de
mise à jour hérite de la super classe transaction de mise à jour des transactions de
base. Une transaction est composée d’un ensemble d’opérations
Le diagramme de classes de ce simulateur est le suivant :
72
CONCLUSION GENERALE
1..* Appliquer
Simulation
Contrôleur de concurrence
1
Protocole
1 Composer d’ordonnancement
1
Contenir
1..*
1..*
Transaction
1..*
0..*
1..*
Données
Mettre à jour
0..*
Consulte
{Complet}
Classique
1
Temps réel
De base Dérivée
1..*
1..*
Composer
Figure V.2 Diagramme de classe du simulateur SGBDTR
73
CONCLUSION GENERALE
Description de la classe 01 : Simulation

La classe Simulation : C'est la classe représentant les paramètres d’une simulation
comme la durée de simulation en ms.
Simulation
Numéro simulation
Durée simulation
Nombre données classiques
Nombre données temps réel
Durée validité minimale de données temps réel
Durée validité maximale de données temps réel
Nombre données temps réel dérivées
Nombre maximum de donnée à drivée à partir de données classique
Nombre maximum de donnée à drivée à partir de données temps réel
Nombre dépendance minimum de données classiques
Nombre dépendance maximum de données classiques
Nombre dépendance minimum de données temps réel
Nombre dépendance maximum de données temps réel
Ajouter ()
Simuler ()
Imprimer les états graphiques ()
Nombre maximum de donnée à drivée à partir de données classique : sert lors de

création de données dérivées.
Description de la classe 02 : Contrôleur de concurrence
Contrôleur de concurrence
Protocole de contrôle de concurrence
Description de la classe 03 : protocole d’ordonnancement
Protocole d’ordonnancement
Protocole d’ordonnancement
74
CONCLUSION GENERALE
Description de la classe 04 : Transaction
Transaction
Numéro transaction
Date arrivée
Date début d’exécution
Périodicité
Durée
Echéance
Etat fin
Générer ()
Exécuter ()
Description de la classe 05 : Données
Représente les caractéristiques de donnée de base parmi les propriétés existe la

propriété table de données dérivées qui sert à définir les différentes données qui
dérivent de cette donnée les paramètres d’une simulation comme la durée de
simulation en ms.
Données
Numéro donnée
Estampillage
Générer ()
Insérer donnée dérivé ()
Libérer donnée dérivée ()
Description de la classe 06 : Donnée classique
Cette classe hérite de la classe Donnée, elle possède un attribut en plus c’est la
table des données dérivées de cette données classique
classique
Table de données dérivées
Insérer donnée dérivée ()
Libérer donnée dérivée ()
Description de la classe 07 : Donnée temps réel
Cette classe hérite de la classe Donnée, elle possède deux attributs en plus c’est la
validité de la donnée et date début de validité
75
CONCLUSION GENERALE
Temps réel
Validité
Date début de validité
Description de la classe 08 : Donnée temps réel de base
Cette classe hérite de la classe Donnée temps réel, elle possède un attribut en plus
la table des données dérivées de cette données temps réel de base
De base
Table de données dérivées
Description de la classe 09 : Donnée temps réel dérivée
Cette classe hérite de la classe Donnée temps réel, elle possède un attribut en plus
la table de dépendances de cette données dérivée.
Dérivée
Liste de dépendances
Calculer validité ()
V.3.2.4 Diagramme de séquence :

Le diagramme de séquence est un diagramme d’interaction mettant l’accent
sur la chronologie de l’envoi des messages. Les diagrammes d’interaction permettent
d’établir un lien entre les diagrammes de cas d’utilisation et les diagrammes de
classes. Ils montrent comment les objets communiquent pour réaliser une certaine
fonctionnalité. Ils apportent ainsi un aspect dynamique à la modélisation du système.
Le schéma suivant décrit les différentes communications entre les objets.
76
CONCLUSION GENERALE
Processus : Simuler un SGBDTR.
: Simulateur
Utilisateur
Utilisateur
Demander une nouvelle simulation
Afficher fiche description des paramètres de la simulation
Remplir la fiche des paramètres
Référencer processus : Générer la base de données
Afficher fiche description des paramètres de transactions temps
Définir les paramètres
Référencer processus : Générer la base des transactions de mise à

jour temps réel
Simuler
Imprimer les états graphiques de la simulation
Figure V.3 processus d’une simulation
77
CONCLUSION GENERALE
Processus : Générer la base de données
: Simulateur
Nombre de données
Loop
: Données
Opt : Données temps réel

Héritier :
Données
Générer l’échéance plus périodicité
: Données
temps réel de
base
Opt : Donnée dérivée Héritier : Données

temps réel
Générer les dérivée
dépendances
Remplir le tableau de dépendances
Figure V.4 : Générer la base de données à simuler.
78
CONCLUSION GENERALE
Processus : Générer la base des transactions
: Simulateur
Nombre de transaction
LOOP
Générer
Créer : Transaction
temps réel
Consulter la liste de ses données dérivées : Donnée temps

réel de base
Nb de données
dérivées
LOOP
Consulter sa validité : Données

dérivées
OPT : Validité
=nulRemplacer
Consulter existence des transactions
de données de base composite
OPT : Existe l’ensemble
Calculer
la
validité
Modifier la validité
Figure V.5 : Générer la base des transactions temps réel
79
CONCLUSION GENERALE
V.4 La mise en œuvre :
Après la phase de conception, où on a présenté les différents diagrammes
nécessaires, on entame la phase de mise en œuvre du simulateur.
Pour la réalisation, nous avons utilisé l’outil de développement Embarcadero RAD

Studio 2010 de Borland qui utilise comme code source C++.
V.4.1 Algorithmes de la génération de données
Une donnée est caractérisé par un numéro séquentiel, on débute par les données
classiques, ensuite les données temps réel de base et à la fin on génère les
données dérivées.
Une donnée temps réel de base est caractérisée par une durée de validité. La durée
de validité est générée aléatoirement à la base des paramètres de validité minimale
et de validité maximale. L’algorithme qui génère les données temps réel de base est
le suivant :
Variables
Nombre_Donnée_Temps_Réel : Entier ; {paramètre d’entrée}
Nombre_Données_Classiques : Entier ; {paramètre d’entrée}
Validité_Min : Entier ; {paramètre d’entrée}
Validité_Max : Entier ; {paramètre d’entrée}
Compteur : entier ;
Début
Pour i := 1.. Nombre_Donnée_Temps_Réel
Faire
Numèro_Donnée_TR := Nombre_Données_Classiques +I ;
Validité_de_la_donnée_temps_réel :=Générer un nombre aléatoire entre la
validité minimale et la validité maximale ;
Fait ;
Fin.
FIN.
V
Figure V.6 Algorithme de la génération des données temps réel de base
80
CONCLUSION GENERALE
Les données dérivées sont soumises à certaines contraintes :
Les données dérivées sont générées à la base de données temps réel et

classiques
Une donnée dérivée dépend au minimum de deux données, dont une donnée
temps réel de base..
En cas d’une donnée dérivée de plusieurs données temps réel de base, la

validité de cette donnée dérivée dépend de la validité de la dernière donnée
de base mise à jour.
La mise à jours d’une donnée de base implique la mise à jours de données

dérivées si cette donnée de base représente la dernière données temps réel
de base déclenchée.
Variables
Nombre_Donnée_Temps_Réel : Entier ; { paramètre d’entrée }
Nombre_Donnée_Temps_Réel_Dérivée :Entier ; { paramètre d’entrée }
Nombre_Min_Données_Classique : Entier ; { paramètre d’entrée }
Nombre_Max_Données_Classique : Entier ; { paramètre d’entrée }
Nombre_Min_Données_Temps Réel_Base : Entier ; { paramètre d’entrée }
Nombre_Max_Données_Temps Réel_Base : Entier ; { paramètre d’entrée }
Compteur,NDC,NDTR : entier ;
Début
Pour i := 1 .. Nombre_Donnée_Temps_Réel_Dérivée
Faire
Numèro_ Donnée_Temps_Réel_Dérivée := Nombre_Donnée_Temps_Réel +I ;
NDC :=Générer_Nombre_Aléatoire_Données_Classique(Nombre_Min_Données_C
lassique ,Nombre_Max_Données_Classique ) ;
J :=1 ;
Tant que J<NDC faire
DCS :=Selectionner_Données_Aléatoire_Classique() ;
Vérifier l’existence DCG parmi les dépendance de cette donnée dérivée
81
CONCLUSION GENERALE
Si inexistante alors
Mettre DCS dans la table de dépendance
J :=j+1 ;
Fin Si
Fait
NDTRB :=Générer_Nombre_Aléatoire_Données_Temps_Réel_Base
(Nombre_Min_Données_Temps_Réel_Base,
Nombre_Max__Données_Temps_Réel_Base);
J :=1 ;
Tant que J<NDTRB faire
DTRS :=Sélectionner_Donnée_Aléatoire_Temps_Réel_Base() ;
Vérifier l’existence DTRS parmi les dépendances de cette donnée dérivée
Si la donnée temps réel de base choisie est inexistante alors
Mettre la donnée choisie dans la table de dépendance
J :=j+1 ;
Fin Si
Fait ;
Fin
Figure V.7 Algorithme de la génération des données temps réel dérivées
Pour générer des nombres aléatoires, on a utilisé les deux fonctions Randomize et
Random.
Pour les transactions de mises à jour temps réel, on a utilisé les transactions
périodiques. On a utilisé un algorithme qui génère ses transactions. Avec cet
algorithme, on génère aléatoirement la date début d’arrivée ainsi aléatoirement la
périodicité et son échéance.
Selon la date d’arrivée de la transaction et sa périodicité, on peut calculer à la base

de la durée de la simulation, sa fréquence d’exécution. Chaque fois la transaction de
mise à jour de la donnée de base est achevée le système doit extraire la liste des
données qui dérivent de cette donnée de base à partir de la propriété table de
données dérivées de cette donnée temps réel de base, le système déclenche
(Trigger)
le programme de mises à jour des données dérivées pour chaque élément de cette
liste.
82
CONCLUSION GENERALE
Le programme déclenché, mettre à jour la donnée dérivée si l’ensemble de ses

données temps réel de base sont actualisées.
V.5 Manuel d’utilisation :
Comme interface principale du simulateur, nous avons choisi d’utiliser une barre de
menu à deux menus. Le sous menu simuler sert à lancer une simulation, et le sous
menu historique sert à consulter les anciennes simulations.
La figure suivante représente l’interface générale de notre simulateur.
Figure V.8 Fiche principale du simulateur
Le sous menu simuler permet de lancer une simulation après l’avoir paramétrée. Le
sous menu historique donne la possibilité à l’utilisateur de consulter les paramètres
et les résultats des simulations déjà effectuées et enregistrées sur la base
d’historisation.
Le menu aide donne à l’utilisateur la possibilité de consulter le manuel d’utilisation

de ce simulateur. Le fichier d’aide est sous forme de diapositives PowerPoint.
Le formulaire de simulation est composé de deux panneaux. Un panneau maître

composé de deux boutons, un pour lancer une simulation et l’autre pour enregistrer
les paramètres de la simulation en cours. Le deuxième panneau détail est destiné
pour lancer et consulter les résultats d’une simulation.
83
CONCLUSION GENERALE
2 4
3 5
1 6
Figure V.9 Fiche de simulation
Cette fiche concerne la fiche de lancement d’une nouvelle simulation, par défaut
seulement le bouton 1 est activé.
Les étapes d’exécution d’une simulation sont définies selon les numéros des
icônes décrites sur la figure V.9.
Le bouton 1 sert à lancer une nouvelle simulation ce qui active le bouton 2 pour
définir les paramètres de la simulation.
Une fois que les paramètres sont définis, le simulateur génère les donnés classiques,
données temps réel de base et dérivée.
La figure suivante représente la fiche de définition des paramètres de la simulation

en cours.
84
CONCLUSION GENERALE
Figure V.10 Fiche de paramétrage
Le bouton valider génère la base de données à simuler
Figure V.11 Liste de données générées
Le bouton Générer les dépendances permet de générer les dépendances de

données dérivée
85
CONCLUSION GENERALE
La figure suivante donne un aperçu sur les données temps réel dérivées générées
par le simulateur.
Figure V.12 Liste de dépendances
D’après cette figure, la données dérivée 101 dépend de 02 données classiques et 01

donnée temps réel.
Pour simuler, on doit générer des transactions temps réel selon les paramètres à
définir à travers la fiche suivante :
Figure V.13 Paramétrage des transactions temps réel
86
CONCLUSION GENERALE
Le bouton validation de cette fiche génère une liste aléatoire de transactions

temps réel.
Figure V.14 Liste des transactions temps réel
A l’aide du bouton 4 : Choisir les protocoles d’ordonnancements et de contrôle de

concurrence.
Figure V.15 Spécification des protocoles d’ordonnancement et de contrôle de concurrence
87
CONCLUSION GENERALE
La fiche définition des protocoles propose 02 méthodes d’ordonnancement EDF-HP

et EDF-CR et 04 méthodes de contrôle de concurrence, dont 2 pessimistes PL-HP,
2PL-WP et 02 optimistes OCC-BC et WAIT-50.
Après la définition des paramètres de la simulation, on utilise le 5ème bouton pour

lancer l’exécution. Une fois la simulation achevée, une fiche de résultats sera
affichée.
Figure V.16 Fiche des résultats
Le bouton visualiser les résultats permet d’afficher une courbe périodique

d’exécution des transactions. L’axe X représente le temps d’exécution en seconde
et l’axe Y représente le nombre de transactions validées.
Figure V.17 Fiche Etat d’évolution d’exécution des transactions
88
CONCLUSION GENERALE
Un autre état graphique sera affiché sous forme secteur qui schématise le nombre
de transactions validées et le nombre de transactions non validées.
Figure V.18 Fiche des états statistiques
Le 06ème bouton : Enregistrer la simulation permet d’enregistrer les paramètres

de la simulation, les données générées, les dépendances et les transactions
validées et non validées.
Pour élaboration des résultats graphiques, on utilise les composants de paquet

TeeChart. On peut consulter les simulations déjà réalisées, à l’aide de sous menu
historique, ce dernier affiche l’ensemble des points de sauvegarde.
Les simulations sont sauvegardées dans une base de données ORACLE 10 G.
La structure des tables de sauvegarde représentent le modèle physique de

diagramme de classe conçue après avoir appliquer les règles de passages au
modèle logique de données relationnelles.
89
CONCLUSION GENERALE
Figure V.19 Fiche Historique
Pour consulter les paramètres et les résultats de la simulation sélectionnée, on

utilise le bouton figurant sur cette fiche.
V.6 Configuration système pour l’intégration du simulateur :
Pour garantir les meilleurs résultats de simulation ; on a utilisé un micro ordinateur

doté d’un processeur Intel Core i7. Cette technologie procure des performances de
premier ordre pour les applications les plus lourdes. Cette puce de deuxième
génération à quatre cœurs assure un multitâche sur huit voies.
Les nouvelles versions de systèmes d’exploitation tiennent en compte les
nouvelles technologies de fabrication des microprocesseurs.
Le système d’exploitation utilisé pour les simulations effectuées est Windows 7,

qui offre aux utilisateurs de définir les processeurs à utilisés pour exécution d’un job
donné, pour notre simulateur on a réservé l’ensemble des processeurs.
Figure V.20 Réservation des processeurs
90
CONCLUSION GENERALE
Le système Windows 7, offre aux utilisateurs la possibilité de définir la priorité d’un

processus donné. Pour notre simulateur, on a défini la priorité Haute car la priorité
temps réel est attribué uniquement pour les processus systèmes.
Figure V.20 Définition de priorité
V.7 Tests :
Le reste de ce chapitre est destiné pour illustrer les résultats des tests réalisés.
Le tableau suivant décrit les paramètres de base de ces tests. Chaque fois, on
change un paramètre pour voir l’effet de ce changement sur le nombre des
transactions validées et non validées.
A travers ce simulateur, on peut tester des protocoles d’ordonnancement et contrôle

de concurrence déjà cités auparavant dans la phase manuel d’utilisation.
N° Paramètre Valeur
01 Durée de la simulation en ms 20000
02 Nombre de données classiques 60
03 Nombre de données temps réel de base 40
04 Nombre de données temps réel dérivées 25
05 Durée de validité d’une donnée temps réel 300..700 ms
06 Nombre de dépendances en données classiques 1..4
07 Nombre de dépendances en données temps réel de base 1..4
91
CONCLUSION GENERALE
08 Protocole d’ordonnancement EDF-HP
09 Contrôleur de concurrence 2PL-HP
10 Durée d’une écriture 2..3
Tableau V.1 Les paramètres de base des tests
Test1 : Selon les paramètres de base, le résultat est le suivant :
Figure V.21 Résultats d’exécution avec les paramètres de base
92
CONCLUSION GENERALE
Test 2 : Avec l’utilisation du protocole d’ordonnancement EDF-CR :
Figure V.22 Résultats d’exécution avec le protocole d’ordonnancement EDF-CR
Test 3 : Avec l’utilisation du contrôleur de concurrence 2PL-WP:
Figure V.23 Résultats d’exécution avec contrôleur de concurrence 2PL-WP
93
CONCLUSION GENERALE
Test 4 : Avec l’utilisation du contrôleur de concurrence OCC-BC :
Figure V.24 Résultats d’exécution avec contrôleur de concurrence OCC-BC
Test 5 : Avec l’utilisation du contrôleur de concurrence WAIT-50:
Figure V.25 Résultats d’exécution avec contrôleur de concurrence WAIT-50
94
CONCLUSION GENERALE
Test 6 : Changement de temps d’une lecture entre 10 et 13 (Augmentation) :
Figure V.26 Résultats d’exécution avec changement de temps d’une écriture
Test 7: Changement du nombre de données temps réel de base avec 60 données:
Figure V.27 Résultats d’exécution avec changement du nombre de données TR de base
95
CONCLUSION GENERALE
Test 8: Changement du nombre de données temps réel dérivées avec 40 données:
Figure V.28 Résultats d’exécution avec changement du nombre de données TR dérivées
Test 9: Changement de validité des données temps réel:
La figure suivante représente le résultat de simulation avec des données temps réel
de validité entre 100..200 ms
Figure V.29 Résultats d’exécution avec changement de validité de données TR dérivées
96
CONCLUSION GENERALE
Test 10: Changement de dépendances des données temps réel dérivées :
On simule pour une liste de dépendances entre 1..7 de données classiques et 1..7
de données Temps Réel de base.
Figure V.30 Résultats d’exécution avec changement de nombre de dépendances
V.8 Analyse des résultats :
D’après les résultats obtenus dans le 2ème test, on peut dire que le protocole
d’ordonnancement EDF-CR est plus performant que le protocole EDF-HP, car le
protocole d’ordonnancement EDF-CR laisse les transactions les moins prioritaires
en phase de validation de terminer leurs exécutions.
Les tests effectués pour la comparaison entre les différents protocoles de

contrôle de concurrence, nous permettent de déduire que les protocoles pessimistes
sont meilleurs que les protocoles optimistes vu le nombre de transactions validées et
non validées.
Pour les deux protocoles optimistes, les tests effectués confirment que le
protocole 2PL-WP est plus fiable que le protocole 2PL-HP, car le nombre de
transactions validées pour le protocole 2PL-WP est plus important que le nombre de
97
CONCLUSION GENERALE
transactions validées pour le protocole 2PL-HP. Le motif est que le premier protocole
2PL-WP permet la continuité d’exécution pour les transactions les moins prioritaire
par la promotion de la transaction détentrice de verrou(s).
Pour le choix d’un protocole de contrôle de concurrence pour la famille optimiste,

les tests confirment que le protocole OPT-WAIT-50 est plus adaptatif que le
protocole OCC-BC vu son module de contrôle d’attente.
L’impact d’un changement de la durée d’une opération d’écriture à un grand effet

sur le nombre de transactions validées démontre que plus la durée est petite, plus
le nombre de transactions validées est plus grand.
Le nombre de dépendance des données dérivées influe sur le déroulement des

transactions. Plus ce nombre est minime, on garanti plus de transactions validées.
Un système de gestion de bases de données temps réel qui manipule un grand

nombre de données dérivées risque d’avoir un grand nombre de transactions non
validées, vu le déclenchement des transactions de mise à jour de données temps
réel à chaque mise à jour de données temps réel.
98
CONCLUSION GENERALE
V.9 Conclusion :
Dans ce chapitre, on a présenté notre simulateur destiné pour le test des

différents protocoles d’ordonnancement et de contrôle de concurrence pour les
SGBD Temps Réel.
Notre simulateur utilise des données temps réel de base ou dérivées, et vu

l’inexistence des benchmark concernant les SGBD Temps Réel, ce simulateur
génère la base de données à simuler.
La conception est une phase incontournable pour la réalisation des systèmes

informatiques. Pour cela, on à conçu à l’aide du langage UML le modèle physique du
simulateur.
Après avoir réalisé le simulateur , on a testé les deux protocoles

d’ordonnancement 2PL-HP et 2PL-WP et les quatre protocoles de contrôle de
concurrence PL-HP, 2PL-WP ,OCC-BC et WAIT-50.
Les résultats des tests effectués donnent aux utilisateurs un aperçu sur l’effet
d’un protocole choisi sur le nombre de transactions validées et non validées.
99
CONCLUSION
GÉNÉRALE
CONCLUSION GENERALE
Conclusion Générale
Les travaux réalisés qui sont présentés dans ce mémoire ont porté sur la
simulation des protocoles d’ordonnancement des transactions temps réel et contrôle
de concurrence d’accès aux données en prenant en considération des données
dérivées avec leurs transactions de mises à jours.
Les principaux points traités ont consisté à :
Faire ressortir la nécessité d’utiliser les SGBD Temps Réel afin de

pouvoir prendre en charge un volume important de données classiques et
temps réel de base ou dérivées.
Prendre connaissance des éléments constitutifs de notre simulateur à

savoir, les données, les transactions temps réel, les protocoles
d‘ordonnancement et les contrôleurs de concurrences appliqués aux SGBD
Temps Réel.
Déterminer les algorithmes d’ordonnancement et contrôle de

concurrence qui seront appliqués dans la réalisation de notre simulateur, qui
sont EDF-HP et EDF-CR pour l’ordonnancement des transactions de mises à
jours et PL-HP, 2PL-WP ,OCC-BC et WAIT-50 pour le contrôle de
concurrence d’accès aux données.
Concevoir le simulateur en définissant ses fonctions et ses paramètres

permettant la génération des données et des transactions, qui pourraient être
sauvegardées dans une base des simulations développée à cet effet.
Implémenter le simulateur et tester les différents protocoles décrits

auparavant, et analyser les résultats obtenus sous forme de graphes .
L’analyse de ces simulations, en utilisant le critère de performance miss ratio (le
nombre de transactions non validées par rapport au nombre total de transactions),
a montré que :
101
CONCLUSION GENERALE
Le protocole d’ordonnancement EDF-CP est meilleur que le protocole
EDF-HP.
Les méthodes de contrôle de concurrence pessimistes sont meilleures que

les méthodes optimistes.
Ces résultats pourraient être utilisés par les concepteurs des SGBD Temps
Réel pour le choix des protocoles.
Ce travail pourrait éventuellement dans l’avenir proche être approfondi et enrichi

en le complétant par les transactions apériodiques en optant pour une autre
approche pluri-disciplinaire. Il s’agit de la technique de réglage par rétroaction
(Feedback Control ), qui repose sur le principe du réglage de la charge du
processeur au niveau des sites. Cette technique est utilisée dans les serveurs web.
102
BIBLIOGRAPHIE
Bibliographie :
[ABB 88] Abbot. R, and Garcia-Molina. H, Scheduling Real-Time Transactions: A
Performance Evaluation, Proc. of the 14th International conference on Very
Large Data Bases, pp 1-12, Los Angeles, California, USA, Mars 1988.
[ABB 89] Abbot. R, and Garcia-Molina. H, Scheduling Real-Time Transactions
with Disk Resident Data, Proc. of the 15th International conference on Very
Large Data Bases, pp 385–396, Amsterdam, The Netherlands, August 1989.
[ABB 92] Abbot. R, and Garcia-Molina. H, Scheduling Real-Time Transactions: A
Performance Evaluation, ACM Transactions on Database Systems, Vol.17,No.3,
pp 513-560, September 1992
[AMI 03] Amirijoo. M, J. Hansson, and S.H. Son, Algorithms for Managing QoS
for Real-Time Data Services Using Imprecise Computation. In proceedings of the
International Conference on Real-Time and Embedded Computing Systems and
Applications(RTCSA), pp 136-157,Taiwan, February 2003.
[Aud 95] N.C. Audsley, Optimal priority assignment and feasibility of static priority
tasks with arbitrary start times , Technical Report YCS-164, University of York
1995.
[Bac 95] Baccouche L, Un mécanisme d’ordonnancement distribué de tâches

temps reel, Thèse de Doctorat, INP Grenoble, Novembre 1995.
[BER 87] Bernstein.P, Hadzilacos. V, and Goodman. N ,Concurrency Control

and Recovery in Database Systems, Addison-Wesley, New York, 1987.
[BOU 08] Bouzefrane.S, Etienne.J, Kaiser.C, Gestion de la surcharge dans les
systèmes de gestion de base de données temps réel, Revue des sciences et
technologies de l’information, ARTICLE VOL 27/7 ,2008.
[BUC 05] Buche P, cours de BDD INA-PG-UER-Informatique2005
[CAZ 08] Alain Cazer, Joëlle Delacroix, Architecture des machines et des
systèmes informatiques 3ème édition Dunond Paris 2008.
[CLI 92]:CliffordW. Mercer, An Introduction to Real-Time Operating

Systems:Scheduling Theory, School of Computer Science; Carnegie Mellon
University; Pittsburgh, Pennsylvania 1992
104
[COT 05] Francis Cottet, Emmanuel Groulleau, Systèmes temps réel de contrôle –
commande Dunod, Paris, 2005.
[DEG 99] Degouel Fabien,Desgeorge Guillaium, Corbel Steve, Synthèse de

protocoles courants Recherche Bibliographique ESEO, 1999.
[DON 02] Donsez D, Le contrôle de la concurrence dans les SGBD, Rapport

d’université Joseph Fourier IMA-IMAG/LSR/ADELE, 2002.
[DUV 99] C. Duvallet, Z.Mammeri, B.sadeg,Les SGBD temps réel, Technique

et sciences informatiques, 1999.
[DUV 99a] Duvallet, C., Mammeri, Z., and Sadeg, B, Analyse des protocoles de
contrôle de concurrence et des propriétés ACID dans les SGBD temps réel.
International Conference on Real-Time and embedded Systems (RTS), Paris,
France,1999.
[ESW 76] Ewaran K.P., Gray J.N., Lorie R.A., Traiger I.L., The Notion of
Consistency and Predicate Locks in a Database System , CACM , Nov. 1976.
[FAB 99] Degouel Fabien, Desgeorge, Guillaume, Corbel Steve, Synthèse de
protocoles courants , Recherche bibliographique ,ESEO, 1999.
[GAR 84] Gardarin Georges, Base de données, les systèmes et leurs langages,
Eyrolles 2ème édition, 1984.
[GAR 00] Gardarin, G, Bases de Données Objet et Relationnelles, Eyrolles,2000.
[GAR 03] Gardarin, G, Les Bases de données : systèmes et langages, (5ème

edition), Eyrolle 2003.
[GRA 78] Gray, J, Notes on Database Operating Systems. Lecture Notes in

Computer Science, 1978.
[GRO 98] Emmanuel Grolleau, thèse de doctorat, Ordonnancement temps réel

hors-ligne optimal à l’aide de réseaux de Petri en environnement
monoprocesseur et multiprocesseur, 1998.
[HAI 05] Jean-Luc Hainaut Bases de données et modèles de calcul Outils et

méthodes pour l’utilisateur, 4ème édition,DUNOD, 2005.
105
[HAR 92] Haritsa, J., Carey, M., and Livny, M, Data Access Scheduling in Firm
Real-Time Database Systems,1992.
[HAR 97] Haritsa, J., Ramamritham, K., and Gupta, R, Characterization and
Optimization of Commit Processing Performance in Distributed Database
Systems, In ACM SIGMOD International Conf on Management of Data,1997.
[HAR 00] Haritsa, J., Ramamritham, K., and Gupta, R, The PROMPT Real,2000
[HON 93] Hong, D., Jonhson, T., and Chakravarty, S, Real-Time Transactions
Scheduling: A Cost Conscious Approach. In proc. of ACM SIGMOD Intl. Conf.
on Management of Data, 1993.
[HUA 90] Huang, J. and Stankovic, J, Concurrency Control in Real-Time
Database System: Optimistic Scheme vs Two-Phase Locking. Technical Report
UM-CS-1990-066, University of Massachusetts,1990.
[HUA 96]Huang, J. and Gruenwald, L, An Update-Frequency-Valid-Interval
Partition Checkpoint Technique for Real-Time Main Memory Databases. In
1stWorkshop on Real-Time Databases(RTDB),1996.
[HUO 04] Huong, H., Hung, D,Modelling Real-Time Database Systems in
Duration Calculus. In Proceedings of the IASTED International Conference on
Databases and Applications (IASTED-DBA 2004), Innsbruck, Austria, 2004.
[JAC 55] J.R. Jackson, Scheduling a production line to minimize maximum
tardiness ,
Research Report UCLA, Management Sciences Research Project, 1955.
[KAN 01] K.D. Kang, S.H. Son, J.A. Stankovic, and T.F. Abselzaher. AQoS-
Sensitive Apprach for Timeliness and Freshness Guarantess in Real-Time
Databases, Technical Report CS-2001-22, Computer Science Department at
University of Virginia, 2001.
[KAN 04] K.D.Kang, S.H. Son et J.A Stankovic, Managing Deadline Miss Ratio
and Sensor Data Freshness in Real-Time Databases, IEEE Transactions on
Knowledge and Data Engineering, Vol. 16, No. 7, Juillet 2004.
[KUN 81] Kung, H. and Robinson, J. (1981). On Optimistic Methods for
Concurrency Control. ACM Transactions on Database Systems
[KUG 81] Kung, H. and Robinson, J, On Optimistic Methods for Concurrency
Control. ACM Transactions on Database Systems, 1981.
106
[LIU 73] C.L. Liu, J.W. Layland, Scheduling algorithms for multiprogramming in
a hard real-time envirronment , Journal of the ACM, vol. 20, n°1, pp. 46-61,
1973.
[LIU 00]. Lu, J.Stankovic , T. Abdelzaher, G.Tao, S.Son, and M.
Marley.Performance specification and metrics for adaptive real-timesystems. In
Real-Time Systems Symposium, Orlando, Florida, Nov. 2000.
[LIU 01] C. Lu, T. Abselzaher, J. Stankovic, and S. Son. A feedback control
approach for guaranteeing relative delays in web servers. In Proc. 7th IEEE
Real-Time Technology and Applications Symposium RTAS 01, Taipei, Taiwan,
May 2001.
[LIU 02] C. Lu, J.A. Stankovic, G. Tao, S.H. Son, Feedback control real-time
scheduling: Framework, modeling and algorithms, In Journal of Real-Time
Systems, vol.23, n°1, p.85-126,2002.
[LOK 01] Locke, D, Applications and system characteristics. In Real-Time
Database Systems: Architecture and Techniques, pages 17–26. Kluwer
Academic Publishers,2001.
[MAM 85]: Mammeri Z,Conception d’applications réparties en commande de
processus : une approche par la structuration de données, Thèse de doctorat,
Institut National Polytechnique de Lorraine, Nancy, 1985.
[MAM 98] Z.Mammeri, Expression et dérivation des contraintes temporelles dans
les applications temps réel , APII-JESA, 1998.
[MAN 99] Manas Saksena , Bran Selic, Real-Time software design-state of the
Art and Future Challenges,IEEE Canadian, 1999.
[MEN 82] Menasce, D. and Nakanishi, T, Optimistic versus pessimistic
concurrency control mechanisms in database management systems, Information
Systems,1982.
[PHI 99]: Philippe M, Bases de données de Merise à JDBC , version 1.4, 1999.
[PUR 94] Purimetla B., Sivasankaran.M., Ramamitham K., Stankovic J.A.,
Real-Time Databases: Issues and Applications , In Principles of RTS, edition.
Printice Hill, 1994.
[RAM 93] K ,Ramamritham . and Chrysanthis, P. K, In Search of Acceptability
Criteria : Database Consistency Requirements and Transaction Correctness
Properties. In Ozsu, T., Dayal, U., and Valduriez, P., editors,Distributed Object
Management. Morgan Kaufmann Publisher, San Mateo, California.
107
[RAM 93a] K.Ramamritham Real-Time Databases, Journal of Distribution and
parallel Databases 1993.
[RAM 00] Ramakrishnan, R. and Gehrke, J. (2000). Database Management
Systems. Mac Graw Hill.
[RAM 03] K.Ramamritham, J.A. Stankovich, K.D. Kang, ‘’ QoS Management in
replicated Real-Time Databases’’, in proceedings of the 24th IEEE real-Time
system syposium (RTSS), (2003).
[RAM 04] K.Ramamritham, S.H. Son, and L.C. Dipippo. Real-Time Data-Time
Databases and Data Services. Real-Time Système, 2004.
[ROQ 07] Pasqual Roques, Franck Vallée, UML2 en action de l’analyse des
besoins à la conception 4e édition EYRollES 2007.
[SHA 87] Sha L, Rajkumar R, Lehoczky J. Priority inheritance protocols: an
approach to real- time synchronization. Technical Report CMU-CS-87, Depts. of
CS, ECE, and Statistics, Carnegie Mellon University, 1987.
[SHA 91] Sha, L., Rajkumar, R., Son, S., and Chang, C. (1991). A real-time
locking protocol. IEEE Transactions on Computers.
[SCH 98]: Scholl P-C., Fauvet M-C. and Canavaggio., “Un modèle d’historique
pour un SGBD temporal”., TSI, vol. 17, n°3,, 1998.
[SON 92]: Son S.H and Liu J.W.S., « How well can data temporal consistency
be
maintained ?», IEEE symp.on Computer.aided Control System Design, 1992.
[SOU 08] Christian Soutou SQL pour Oracle 3e edition EYROLLES 2008
[STA 88] J. Stankovic and K. Ramamritham. Hard real-time systems: a tutorial.
IEEE Computer Society Press, 1988.
[STA 99].Misconception about Real-Time Databases, J.A. Stankovic, S.H. Son,
J. Hansson Systems, IEEE Computer, Vol. 32, No. 6, pp. 29-36,June 1999.
[SAD 04] Bruno Sadeg Habilitation à Diriger des Recherches Contributions ` a
la gestion des transactions dans les SGBD temps réel 2004
[TAN 10] Andrew Tanenbaum, Systèmes d’exploitation, 3ème edition Pearson
Education France.
[ULM 80] Ullman, J. (1980). Principles of Database Systems and Knowledge
Base Systems . Computer Science Press, Inc., Maryland.
[WAN 02] Wang, Z., Song, Y., Poggi, E., and Sun, Survey of Weakly-Hard Real-
Time Scheduling theory and Its Application DCABES 2002.
108
[WEI 03]. QoS Management in Replicated Real-Time Databases, Y.Wei, S.H.
Son, J.A. Stankovic, K.D. Kang, Proceedings of the 24th IEEE International Real-
Time Systems Symposium, pp.86-97, 2003.
[XIO 96] Xiong, M., Stankovic J.A., Ramamritham K., Towsley D. and
Sivasankaran R.M., «Maintaining temporal consistency: issues and algorithms
», 1Int. Workshop on RTDBS.Issues and Applications, , California 1996.
[XIO 02] M. Xiong, K.Ramamritham, J.R Haritsa, and J. A. Strankovic.
Mirror: a stat-Conscious Concurrency Control Protocol for Replicated real-
Time Databases. Inf. syst.2002.
109

1 MAGISTER Simulation Des Protocoles Dordonnancemen PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

1 MAGISTER Simulation Des Protocoles Dordonnancemen PDF

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur et de la Recherche

Option : Ingénierie des Systèmes Informatiques

Par : M. BERKOUK M OHAMED

Simulation des protocoles d’ordonnancement

Soutenu publiquement le 15 Mars 2012 devant le jury composé de :

Mr. BALLA Amar, Professeur ESI, Président

Mr. HIDOUCI Walid-Khaled, Maître de conférences A ESI, Directeur de thèse

À tous ceux que nous aimons

CHAPITRE I : Systèmes temps réel et ordonnancement

I.2- Systèmes temps réel 15

I.3- Type de systèmes informatiques 16

I.4- Domaine d’application 16

I.5- Structure des systèmes temps réel 16

I.6- Fonctionnement des systèmes temps réel 17

I.7- Caractéristique temporelle des systèmes temps réel 18

I.8- Types des STR 18

I.9- Caractéristiques des STR 19

I.10- Tâche temps réel 20

I.10.2- Modèles de tâches 21

I.10.2.2- Les tâches sporadiques 22

I.10.2.3- Tâches apériodiques 23

I.10.3- Caractéristiques d’une tâche temps réel 23

I.10.4- Diagramme état-transition d’une tâche 24

I.11- Ordonnancement des tâches 24

I.11.1- Ordonnancement hors ligne 25

I.11.2- Ordonnancement en ligne 25

I.12.1- Algorithmes à priorité fixes 26

I.12.1.1- Algorithmes Rate Monotonic 26

I.12.1.2- L’algorithme d’ordonnancement Deadline Monotonic 27

I.12.2- Les algorithmes à priorité variable 28

I.12.2.1- Earliest Deadline First 28

I.12.2.2 Least Laxity First 29

CHAPITRE II : Systèmes de gestion de bases de données

II.2- Introduction aux SGBD 32

II.3- Les transactions pour les SGBD classique 33

II.4- Les propriétés ACID des transactions 34

II.5- Anomalies transactionnelles 35

II.5.1- Perte de mise à jour 35

II.5.2- Mises à jour temporaires ou lecture impropre 36

II.5.3- Lecture non reproductible (fantôme) 36

II.6- Contrôle de concurrence 37

II.6.1- Méthodes optimistes 37

II.6.2- Méthodes pessimistes 38

II.7- Le verrouillage à deux phases 39

II.7.1- La notion d’interblocage 40

II.7.2- La notion de famine 41

II.8.1- Ordonnancement total 43

II.8.2- Ordonnancement partiel 43

CHAPITRE III : Systèmes de gestion de bases de données temps réel

III.2- Données temps réel 47

III.3- Formalisation de la cohérence 50

III.4- Les propriétés ACID des transactions temps réel 52

III.5- Classement des transactions temps réel 52

III.5.1- Classement des transactions temps réel selon le type d’objet 52

III.5.2- Classement des transactions temps réel selon l’échéance 53

III.6- Qualité de service 55

III.7- Marché des SGBDTR 56

CHAPITRE IV : Protocoles d’ordonnancement et contrôle de concurrence

IV.2- Les protocoles d’ordonnancement et contrôle de concurrence 59

IV.2.1- Techniques optimistes 60

IV.2.1.1- OCC-BC (Optimistic Concurrency Control-Broadcast Commit) 60

IV.2.1.3- Protocole OCC-BC – OPT – WAIT 61