les systèmes de gestion de bases de données...

Les Systèmes de Gestion de Bases de DonnéesTemps Réel et Multimédia

—Année 2007-2008

Claude Duvallet

Université du HavreUFR Sciences et Techniques

25 rue Philippe Lebon - BP 54076058 LE HAVRE CEDEX

[email protected]://litis.univ-lehavre.fr/∼duvallet/

Novembre 2007

Claude Duvallet - 1/223 Les SGBD temps réel

Qui suis-je ? [2/223]Claude Duvallet

Maître de conférences en Informatique depuis septembre 2003.Thèse de doctorat soutenue le 5 octobre 2001 à l’université duHavre, France

D’où je viens ? Université du Havre (France).Mon domaine d’activité :

Enseignements : programmation (Java, C/C++,...), systèmesd’exploitation (Linux, Unix), systèmes distribués (CORBA, RMI,RPC, EJB, LDAP, etc.), architecture et protocoles réseaux,administration des systèmes et réseau sous linux.Recherche : SGBD temps réel, systèmes multimédia, gestion dela qualité de service, systèmes distribués, etc.

Co-encadrement de doctorants Tunisiens : Nizar Idoudi et EmnaBouzizi.Collaborations de recherche avec l’ISIM et la FSEG de SFAX,l’université de Monastir, l’INSAT de Tunis, et l’université deGabès.


Objectifs du cours [3/223]

Les Systèmes de Gestion de Bases de Données Temps Réel.Les concepts étudiés :

Les systèmes temps réel.Les SGBD temps réel : notions de transactions temps réel, dedonnées temps réel, de données dérivées temps réel,d’ordonnancement, de contrôle de concurrence, de gestion de laqualité de service...


Introduction et contexte [4/223]

Des applications informatiques :qui sont de plus en plus sophistiquées en termes de traitements etde données.qui utilisent des données avec une période de validité limitée dansle temps.qui doivent fournir des résultats avant une échéance donnée.

Exemple : les systèmes de surveillance de sites industriels àhauts risques :

ils font appels à de nombreux domaines (chimie, météo, sécuritécivile) =⇒ utilisation de nombreuses données.ils utilisent des données acquises à partir de capteurs(température, pression, ...) qui changent souvent de valeurs.ils doivent prévenir les utilisateurs (décideurs) suffisamment tôtpour éviter de potentielles catastrophes.


Un autre exemple d’application : les systèmes de vidéo à lademande [5/223]

Principe :Un serveur qui met à disposition des contenus vidéo (des films).Des clients qui effectuent des demandes et visualisent cescontenus en temps réel sans les téléchargé mais au moyen d’unclient (lecteur) supportant le streaming vidéo.

Problématique temps réel :Des contenus multimédia qui représentent des quantités dedonnées très importantes.Des contraintes temps réel : les morceaux de films qui sonttransmis par le biais du réseau doivent être joués dans des délaisimpartis pour aboutir à une certaine fluidité et éviter les problèmesde synchronisation entre le son et la vidéo.

Les protocoles utilisés : RTSP/RTCPLes paquets vidéo sont transmis au format RTP (Real-TimePacket) : chaque paquet doit arrivé avant la fin de la lecture duprécédent pour pouvoir être joué.


Introduction et définitionsLes applications temps réel

Les architectures des systèmes temps réelL’ordonnancement des tâches temps réel

Les Systèmes Temps Réel




Les systèmes temps réel [7/223]

Introduction et contexte : quelques définitions.

Les applications temps réel.

Les architectures des systèmes temps réel.

L’ordonnancement des tâches temps réel.

Les systèmes temps réel distribué.

L’ordonnancement des tâches et les messages temps réel.




Introduction (1/2) [8/223]

Le temps : rôle de + en + important dans les services et lesapplications (informatique industrielle, télécommunications,...).

Informatique industrielle : prémisses de l’informatique temps réel.En télécommunication :

(1) débits élevés : la durée du trafic est bornée,(2) plusieurs flux d’information : synchronisation nécessaire

(multimédia).

Les services : à chaque service est liée une qualité de service(QoS) : temps d’établissement d’une connexion, temps deréponse d’une requête, etc.




Introduction (2/2) [9/223]

Maîtrise du temps : d’abord, plus de puissance de calcul, puisapparition de mécanismes “légers” (moins de temps gaspillé pourdes parties non liées à l’application), enfin méthodes pour prédireles comportements temporels.

Plusieurs mécanismes à mettre en œuvre dans un OS poursupporter les applications temps réel, notammentl’ordonnancement des tâches.




Définition d’un système temps réel [10/223]

Un système temps réel est un système dont le comportementdépend non seulement de l’exactitude des traitements effectués, maiségalement du temps où les résultats de ces traitements sont fournis.C’est-à-dire qu’un retard dans la production d’un résultat est considérécomme une erreur (pouvant entraîner de graves conséquences).




Schéma d’une application temps réel [11/223]

événements

commandes

affichage

Système informatiquede contrôle

− automate

− mono−processeur

− multi−processeur

− réseau local

Procédé

− équipement élémentaire

− procédé complexe

− ensemble d’équipement

Actions

mesures

Observations




Illustrations/Exemples [12/223]

Système temps réel : calcul de la position d’un bateau enmouvement. Même si le résultat fourni est exact, il est considérécomme erroné s’il est fourni en retard (le bateau a changé deposition)

Système non temps réel : gestion de notes des élèves. Si lesmoyennes calculées sont exactes alors le système est correct(aux arrondis près)




Types de temps réel [13/223]

échéance dure (hard) : l’obtention d’un résultat en retardprovoque une exception dans le système.

échéance molle, lâche (soft) : le retard ne provoque pasd’exception

STR durs : les échéances ne doivent en aucun cas êtredépassées (sinon catastrophes humaines, technologiques, ...)

STR mous : les échéances peuvent être dépasséesoccasionnellement (usines automatisées)




Caractéristiques des systèmes temps réel (1/2) [14/223]

La prévisibilité : un STR doit être conçu tel que sesperformances soient définies dans le pire cas.

Dans les systèmes classiques : les performances sont définies entermes de moyenne.La prévisibilité permet de savoir à l’avance si un système varespecter ses contraintes temporelles (connaître avec précisionles paramètres : temps global de calcul de chaque activité, lapériodicité, etc.).

L’ordonnancement : choix d’une politique d’ordonnancementdes activités de façon à ce que le système soit prévisible.




Caractéristiques des systèmes temps réel (2/2) [15/223]

Le déterminisme : ce doit être un but à atteindre pour assurer laprévisibilité : il faut enlever toute incertitude sur le comportementdes activités (individuelles et mises ensemble).

Dans les STR "dur", on cherche à ce que toutes les échéancessoient respectées.

Dans les STR "mou", on cherche à minimiser le retard moyen desactivités par exemple.




Non-déterminisme et déterminisme dans les STR [16/223]

Les sources du non-déterminisme :Charge de calcul (durées d’exécution variées).Entrées/sorties sur disque.Interruption : temps de réaction du système.Fautes et exceptions matérielles et logicielles.

Remarques :Le déterminisme absolu est difficile à atteindre.Mais, on améliore par des méthodes d’ordonnancement quianalysent a priori le comportement temporel du système.




La fiabilité (reliability) [17/223]

Un autre aspect important des STR.

Il est difficile de prédire le comportement d’un système dont lescomposants ne sont pas fiables.

Il est donc nécessaire de concevoir des systèmes tolérants auxfautes.

Par exemple : les systèmes temps réel embarqués (real-timeembedded systems).




Les systèmes embarqués [18/223]

Pas d’intervention humaine directe.

Ils doivent être prévisibles (et fiables).

Exemple : les rames de métro automatique, le pilotageautomatique d’avion, le contrôle de navette spatiale,...

Ce sont des systèmes dédiés : ”taillés spécialement” pour unetâche précise notamment en termes de ressources etéventuellement de redondance des ressources.




Exemples d’application [19/223]

1. Le robot : doit prendre des objets qui défilent sur un tapisLe robot dispose d’une “fenêtre temporelle” pour agir.S’il agit trop tard, il manquera l’objet.S’il agit trop tôt, il va bloquer l’objet (et les objets suivants).

2. Système de vidéo-conférence : sur un réseau local.Le système numérise l’image, puis la séquence. Il faut que soienttraitées 30 images/sec pour une image acceptable.Plusieurs opérations vont s’enchaîner dans le temps :numérisation, compression, transmission. La durée de cesopérations = temps de latence du système.La voix doit également être numérisée, compressée et transmise.Il faut qu’il y ait synchronisation son/image. Un retard léger estacceptable. S’il est trop long, la scène devient incompréhensible(temps réel mou, ou échéances molles, relatives).




Limites des STR classiques pour le temps réel [20/223]

Reposent sur un OS qui offre des mécanismes mal adaptés autemps réel

politiques d’ordonnancement visent le partage équitable du tempsd’exécution. Pas adaptées à des tâches plus critiques qued’autres.les mécanismes d’accès aux ressources partagées sont à adapterpour éliminer les incertitudes temporellesla gestion des E/S engendrent de longues attentes (parfois nonbornées)la gestion des interruptions n’est pas optimiséeles mécanismes de gestion de la mémoire virtuelle sont à revoir(swapping, ...)les temporisateurs qui organisent le temps n’ont pas unerésolution assez fine (pour beaucoup d’applications temps réel)




Sources d’incertitude [21/223]

On ne dispose pas de moyens pour indiquer à au systèmed’exploitation le degré d’urgence d’une tâche.

Le temps de réponse des événements externes n’est pasprévisible :le système n’indique rien sur la durée de prise en compte d’uneinterruption.




Terminologie [22/223]

Le noyau : il rend l’ensemble des services de base nécessaires àl’exécution d’une application (gestion mémoire, processeur,adressage, interruptions,...).

L’exécutif : il rend les services du noyau plus d’autres sanstoucher à l’interface utilisateur (surtout pour les systèmesembarqués).

le système d’exploitation : noyau + exécutif + interaction avecl’utilisateur.




Terminologie pour l’ordonnancement des tâches temps réel [23/223]

Tâche = unité de base de l’ordonnancement temps réel.Les tâches peuvent être soit périodiques soit apériodiques.Les tâches peuvent être à contraintes temporelles strictes ourelatives.

Modèle : paramètres chronologiques (délais) et chronométriques(dates). Les paramètres de base d’une tâche sont :

r : sa date de réveil, moment de déclenchement de la 1ere requêted’exécution.C : sa durée maximale d’exécution (si elle dispose du processeurà elle seule).D : son délai critique (délai maximal acceptable pour sonexécution).P : sa période (si tâche périodique).S’il s’agit d’une tâche à contraintes strictes, l’échéance d = r + Dest la date dont le dépassement entraîne une faute temporelle.




Illustration : diagramme temporel d’exécution [24/223]

D

C

P P

r0 d0 r1 d1 r2

temps

FIG.: Modèle des tâches




Commentaires [25/223]

T (r0, C, D, P) avec 0 ≤ C ≤ D ≤ P

r0 : date de réveil, C : durée max d’exécution,D : délai critique, P : période

rk : date de réveil de la keme requête de la tâche.rk = r0 + k P, représentée par ↑dk : échéance de la keme requête de la tâche.dk = rk + D, représentée par ↓Remarque : On appelle tâche à échéance sur requête unetâche pour laquelle D = P, représentée par l




Remarques [26/223]

Tâche à contraintes relatives : D parfois omis

Tâche apériodique : pas de paramètre P

Plus les paramètres précédents sont exactes, plus la qualité del’ordonnancement est meilleure




Autres paramètres déduits [27/223]

u = CP (doit être ≤ 1) : facteur d’utilisation du processeur par la

tâche

ch = CD doit être (≤ 1) : facteur de charge du processeur

paramètres dynamiques (pour suivre l’exécution d’une tâche) :s : date de début de l’exécution d’une tâchee : date de fin d’exécution d’une tâcheD(t) = d− t : délai critique résiduel à la date t (0 ≤ D(t) ≤ D)C(t) = durée d’exécution résiduelle à la date t (0 ≤ C(t) ≤ C)L = D−C laxité nominale de la tâche, retard maximum pour sondébut d’exécution s quand la tâche s’exécute seule.L(t) = D(t)−C(t) laxité nominale résiduelle, retard maximumpour reprendre l’exécution d’une tâche si elle s’exécute seule(L(t) égal aussi D + r − t−C(t)).TR = e− r : temps de réponse de la tâcheCH(t)= C(t)[27/223]

D(t)[27/223] : charge résiduelle au temps t




Les états d’une tâche (1/2) [28/223]

Une tâche peut être dans plusieurs états :

élue : un processeur est alloué à la tâche.

bloquée : la tâche attend une ressource, un message ou unsignal de synchronisation.

prête (éligible) : la tâche attend d’être élue.

passive : la tâche n’a pas de requête en cours.

inexistante : la tâche n’est pas créée.




Les états d’une tâche (2/2) [29/223]

ELUE

PRETEBLOQUEE

PASSIVEINEXISTANTE

faute temporelle

faute

temporelle




Les autres caractéristiques d’une tâche (1/2) [30/223]préemptible : tâche élue qui peut être arrêtée et remise à l’étatprêt, pour allouer le processeur à une autre tâche.non préemptible : une fois élue, la tâche ne doit plus êtreinterrompue jusqu’à la fin de la requête (tâches atomiques, àexécution immédiate).tâches indépendantes : lorsqu’elles n’ont pas de relations deprécédence et ne partagent pas de ressources critiques.tâches dépendantes :

par une relation de précédence statique : si elles agissent selonun ordre prédéterminé, ou induit par la communication parmessages ou par une relation explicite de synchronisation. Elleest statique car connue a priori. On peut construire le graphe dedépendances.par une relation de précédence dynamique : si elles partagent desressources critiques (accès en exclusion mutuelle). La relation estdynamique car l’utilisation de la ressource dépend de l’ordred’exécution des tâches.




Les autres caractéristiques d’une tâche (2/2) [31/223]

priorité externe (fixe) : forme primitive d’ordonnancement tempsréel. Tout est déterminé par un ordonnancement hors ligne ou pardes règles qui imposent un ordre a priori (ex : tâche de gestionde l’horloge, tâche de sauvegarde en cas de chute de tension)

urgence : tâches de même urgence → même échéance.importance :

tâches pouvant être supprimées en premier dans certains caspour permettre aux autres (plus importantes) de respecter leurscontraintes.2 tâches de même urgence peuvent avoir des importancesdifférentes.




Ordonnancement des tâches temps réel (1/2) [32/223]

Son but est de permettre le respect des contraintes temporellesdes tâches d’une application quand elle s’exécute en modecourant.

Il doit être certifiable, c-à-d prouver a priori le respect des C.T.des tâches d’une application (en régime courant).

En régime de surcharge (tâches supplémentaires suite à desanomalies : alarmes, variations des temps d’exécution, → fautestemporelles...) : l’ordonnancement doit offrir une tolérance auxsurcharges (permettre une exécution dégradée mais sécuritairedu système).

Configuration de tâches : mise en jeu d’un ensemble de n tâchesqui s’exécutent

Départ simultané : même date de réveil (sinon départ échelonné).




Ordonnancement des tâches temps réel (2/2) [33/223]

Facteur d’utilisation du processeur pour n tâches périodiques :

U =i=n

∑i=1

Ci

Pi.

Facteur de charge du processeur pour n tâches périodiques :

CH =n

∑i=1

Ci

Di.

Laxité du processeur à l’instant t , LP(t) = intervalle de temps àpartir de t pendant lequel le processeur peut rester inactif sansremettre en cause le respect des échéances (LP(t) ≥ 0, ∀ t).LP(t) est égale au minimum des laxités conditionnelles LCi(t)des tâches i .LCi(t) = Di - ∑j Cj(t)[33/223]. Les tâches j sont celles qui sontdéclenchées à l’instant t et qui devancent i dans la séquence deplanification.




Définition du problème d’ordonnancement [34/223]

Le système de conduite d’une application temps réel doit piloterle procédé en ordonnançant les tâches avec 2 objectifs :

assurer le respect des C.T. en fonctionnement nominalatténuer les effets des surcharges et maintenir le procédé dans unétat cohérent et sûr en fonctionnement anormal (pannesmatérielles ou logicielles) → respecter au moins les CT desrequêtes vitales pour le procédé

L’algorithme d’ordonnancement fournit une description de laséquence de planification de tâches à effectuer de manière àrespecter les CT.




Typologie des algorithmes d’ordonnancement (1/5) [35/223]

Algorithme hors ligne :L’algorithme construit la séquence complète de planification destâches sur la base de tous les paramètres temporels des tâches.La séquence est connue avant l’exécution.Très efficace, mais cette approche statique est rigide car ellesuppose que tous les paramètres, y compris les dates de réveil,sont figées → ne s’adapte pas aux changements del’environnement.





Algorithme en ligne :Il est capable à tout instant de l’exécution d’une application dechoisir la prochaine tâche à ordonnancer, en utilisant lesinformations des tâches déclenchées à cet instant.Ce choix peut être remis en cause par l’occurrence d’un nouvelévénement.Cette approche dynamique offre des solutions moins bonnes (carelle utilise moins d’informations) et entraîne des surcoûts de miseen œuvre.Les avantages :

permet l’arrivée imprévisible des tâches,autorise la construction progressive de la séquenced’ordonnancement.

Pour pouvoir traiter les tâches apériodiques (et les surchargesanormales), l’ordonnancement se fait souvent en ligne.





Algorithme préemptif :Il permet à l’ordonnanceur de déposséder la tâche élue duprocesseur au profit d’une autre tâche jugée plus prioritaire.Il n’est utilisable que si toutes les tâches sont préemptibles.La tâche ayant perdu le processeur passe à l’état prêt pour êtreélue ultérieurement sur le même processeur ou sur un autre.

Algorithme non préemptif :Il n’arrête pas l’exécution d’une tâche élue.Des fautes temporelles peuvent se produire alors qu’unalgorithme préemptif les aurait évitées.





Meilleur effort (best effort) :Il est utilisable pour une application à contraintes relatives.La stratégie d’ordonnancement est celle du meilleur effort : elleessaie de faire au mieux avec les processeurs disponibles.

Pour une application à contraintes strictes :L’ordonnanceur doit garantir le respect des CT.Il y a obligation de réussite et non tolérance aux fautestemporelles.





Centralisé :Si l’algorithme d’ordonnancement s’exécute sur une architecturecentralisée (ou sur un site privilégié d’une architecture distribuée,qui contient tous les paramètres des tâches).

Distribué :Lorsque les décisions d’ordonnancement sont prises sur chaquesite par un ordonnanceur local après une éventuelle coopérationpour effectuer un ordonnancement global.Pour l’ordonnancement global, le placement des tâches sur unsite peut intervenir et la migration des tâches d’un site à un autre.




Propriétés des algorithmes d’ordonnancement (1/3) [40/223]

Séquence valide : un algorithme d’ordonnancement délivre uneséquence d’ordonnancement valide pour une configuration detâches donnée si toutes les tâches respectent leur CT.

Une configuration est ordonnançable dès qu’il existe au moinsun algorithme capable de fournir une séquence valide pour cetteconfiguration.

Algorithme optimal : un algorithme est optimal s’il est capablede produire une séquence valide pour toute configuration detâches ordonnançables.

Test d’ordonnançabilité : il vérifie qu’une configuration detâches périodiques donnée soumise à un algorithmed’ordonnancement peut être ordonnancée selon une séquencevalide.





Test d’acceptabilité :Un algorithme en ligne modifie dynamiquement la séquenced’ordonnancement à l’arrivée de nouvelles tâches (ou à la suitede dépassement d’échéances).Une tâche nouvelle peut être ajoutée à la configuration s’il existeau moins une séquence valide avec la nouvelle configuration(tâches existantes + celle ajoutée).L’ensemble des conditions à satisfaire est le test d’acceptabilité(routine de garantie).Dans un ordonnancement réparti, le rejet d’une requête par cetest peut être résolu en essayant de migrer la tâche sur un autresite.





Période d’étude : pour valider une configuration de tâchespériodiques et apériodiques, on effectue une analyse temporellede l’exécution de la configuration.

Pour les tâches périodiques : il suffit d’effectuer l’analyse sur unepériode (car la configuration est périodique, et se répèteindéfiniment).

Début de la période d’étude : t = Min{ri0}, c-à-d date de réveil dela première requête de la première tâche de la configuration.

Fin de la période d’étude : Max{ri , 0, rj , Dj } + 2*PPCM(Pi ), i :tâches périodiques, j : tâches apériodiques (PPCM(Pi )seulement, si périodiques).




Mise en œuvre d’un ordonnanceur [43/223]

Table d’élection : lorsque la séquence est connue a priori(ordonnancement hors ligne), cette séquence est inscrite dansune table consultée par l’ordonnanceur pour élire les tâches.

Liste d’attente avec priorités : l’ordonnancement en ligne ⇒création dynamique d’une séquence de planification.Le premier élément indique la tâche élue (si monoprocesseur),les n premiers, si n processeurs.La liste est ordonnée selon les clés (priorités).

Priorité fixe : dans la liste d’attente, la clé (priorité) est fixe si onprend un paramètre fixe comme clé (durée d’exécution, délaicritique, période).

Priorité variable : si on prend comme clé un paramètre variable(date de réveil, échéance,...).




Ordonnancements classiques [44/223]

Objectifs :maximiser le taux d’utilisation du processeur,minimiser le temps de réponse des tâches (durée séparantl’instant de soumission au système de l’instant de fin d’exécution).

Autres critères :temps d’attente des tâches (état prêt),débit du processeur (nombre de tâches traitées par unité detemps),moyenne du temps de réponse d’un ensemble de tâches), ...




Principales politiques d’ordonnancement (1/4) [45/223]

⇒ déterminer quelle tâche prête doit être élue

Premier arrivé, premier servi (les tâches de faible tempsd’exécution sont pénalisées si elles sont précédées dans la filepar une tâches de longue durée).

Plus court d’abord : remédie à l’inconvénient précédent. Minimisele temps de réponse moyen. Pénalise les travaux longs. Elleimpose d’estimer les durées d’exécution des tâches (connuesdifficilement).

Temps restant le plus court d’abord : la tâche en exécutionrestitue le processeur lorsqu’une nouvelle tâche ayant un tempsd’exécution inférieur à son temps d’exécution restant devientprête.




Principales politiques d’ordonnancement (2/4) [46/223]Tourniquet (Round Robin) :

On définit un quantum de temps (10ms à 100ms).Chaque tâche de la file acquiert le processeur pendant aumaximum un quantum de temps, puis le cède à sa suivante dansla file, etc.

→ utilisée souvent dans les système à temps partagé.Ses performances dépendent du quantum de temps : s’il est tropgrand, on augmente les temps de réponse, s’il est trop petit, onmultiplie les commutations de contextes.

Priorités constantes :Des priorités sont affectées aux tâches et à un instant donné, latâche élue est celle qui a la plus forte priorité.Les tâches de faible priorité peuvent ne pas disposer duprocesseur (famine).Solution : faire “vieillir” la priorité des tâches en attente(augmenter en fonction du temps d’attente). La priorité devientainsi variable (et donc non constante !)





Files de priorités constantes multi-niveaux :On définit plusieurs files de tâches prêtes.Chaque file correspond à un niveau de priorité (n files de prioritésvariant de 0 à n-1 : file i , tâches de même priorité).Elles sont gérées soit par ancienneté soit par tourniquet.Le quantum peut être différent selon la file.L’ordonnanceur sert d’abord les tâches de la file 0, puis celles dela file 1 (dès que la 0 se vide), etc.





Deux variantes des files de priorités constantes multi-niveaux :les priorités des tâches sont constantes tout au long de leurexécution : une tâche en fin de quantum est réinsérée dans lamême file.les priorités des tâches évoluent dynamiquement en fonction desservices dont elles ont déjà bénéficié. Une tâche de la file x , quin’a pas terminé son exécution à la fin de son quantum estréinsérée dans la file x +1 (moins prioritaire), etc.

⇒ On minimise ainsi les risques de famine des tâches de faiblepriorité en diminuant petit à petit les priorités des tâches ayant defortes priorités initiales.

Remarque :Aucune des politiques présentées ne permet de remplir les 2objectifs d’un ordonnancement temps réel.Notament : pas de prise en compte de l’urgence des tâches (délaicritique)




Ordonnancement Rate Monotonic (1/3) [49/223]

Algorithme d’ordonnancement en ligne, à priorité constante pourtâches indépendantes.

Priorité d’une tâche = fonction(sa période). La tâche de pluspetite période est la plus prioritaire.L’algorithme est optimal dans la classe des algorithmes à prioritéconstante pour une configuration de tâches à échéances surrequête.

Dans ce cas, on connaît une condition suffisante d’existenced’une borne minimale pour l’acceptation d’une configuration de ntâches :

n

∑i=1

Ci

Pi≤ n(2

1n −1)

Cette borne représente le pire cas et tend vers ln 2 quand n trèsgrand (c-à-d 69%). Elle peut être dépassée (en moyenne elle estde 88%)





Exemple : la figure du transparent suivant montre un exempled’ordonnancement “Rate Monotonic” pour 3 tâches périodiques àéchéance sur requête (échéance=période) :

T1(r0 = 0,C = 3,P = 20), T2(r0 = 0,C = 2,P = 5),T3(r0 = 0,C = 2,P = 10). Tâche de plus haute priorité : T2,tâche de plus basse priorité : T1.

La séquence d’étude est l’intervalle [0, 20]1.

Les 3 tâches respectent leur CT car la condition suffisante estvérifiée : on a bien 3

20 + 25 + 2

10 ≤ 0.77.

Remarque : l’utilisation de la période comme critèred’ordonnancement limite l’application de “Rate Monotonic” auxseules tâches où l’échéance est égale à la période (échéancessur requête).

1Configuration à départ simultané, période d’étude [0, PPCM(Pi )]Claude Duvallet - 50/223 Les SGBD temps réel




0

20

0

0

4 5

2 5 7 10 12 15 17

20

20

207 9

2 4 10

temps

temps

temps

12 14

T1 (r0=0, C=3, P=20)

T2 (r0=0, C=2, P=5)

T3 (r0=0, C=2, P=10)




Ordonnancement Inverse Deadline ou Deadline Monotonic(1/3) [52/223]

Algorithme d’ordonnancement en ligne, à priorité constante pourtâches indépendantes.

Priorité d’une tâche = fonction(son délai critique).

La tâche la plus prioritaire est celle de plus petit délai critique.

Cet algorithme est égal en performances à “Rate Monotonic”pour les tâches à échéances sur requête, et meilleur pour lesautres types de configurations de tâches.

Condition suffisante d’acceptabilité :n

∑i=1

Ci

Di≤ n(2

1n −1)





Exemple : la figure sur le transparent suivant montre l’exemple d’unordonnancement “Deadline Monotonic” pour 3 tâches périodiques :

T1(r0 = 0,C = 3,D = 7,P = 20), T2(r0 = 0,C = 2,D = 4,P = 5),T3(r0 = 0,C = 2,D = 9,P = 10).Tâche de plus haute priorité : T2, tâche de plus basse priorité :T3.

La condition suffisante n’est pas vérifiée :37 + 2

4 + 29 = 1.14 > 0.77.

Cependant, le chronogramme construit sur la période d’étudemontre qu’elles sont ordonnançables sans faute temporelle.





0

0

temps

temps

temps

0

2 5 7 20

20

2019

19171514121097542

4 5 7 9 10 12 14

T2 (r0=0, C=2, D=4, P=5)

T3 (r0=0, C=2, D=9, P=10)

T1 (r0=0, C=3, D=7, P=20)




Ordonnancement Earliest Deadline (1/3) [55/223]

Algorithmes en ligne à priorité variable : la priorité varie dans letemps.

La plus haute priorité à l’instant t est accordée à la tâche dontl’échéance est la plus proche.

Pour les tâches à échéances sur requête, une condition non

suffisante d’ordonnancement est :n

∑i=1

Ci

Pi≤ 1

Pour des tâches périodiques quelconques, une condition

suffisante est :n

∑i=1

Ci

Di≤ 1 et une condition nécessaire est :

n

∑i=1

Ci

Pi≤ 1.





Exemple : la figure du transparent suivant montre l’exemple d’unordonnancement “Earliest Deadline” pour 3 tâches périodiques.T1(r0 = 0,C = 3,D = 7,P = 20), T2(r0 = 0,C = 2,D = 4,P = 5),T3(r0 = 0,C = 1,D = 8,P = 10).

À t=0, les 3 tâches se réveillent, T2 est prioritaire, elle s’exécutependant 2 unités.

À t=2, T2 termine. C’est T1 la plus prioritaire. Elle s’exécutependant 3 unités de temps.

À t=5, T1 se termine et T2 se réveille de nouveau (car période 5),mais c’est T3 qui est cette fois la plus prioritaire car son échéanceest 8, elle s’exécute pendant une unité.

Ici, on voit que les priorités des tâches varient dans le temps : parexemple, à t=0, c’est T2 la plus prioritaire (que T1 et T3), mais àt=5, c’est T3 la plus prioritaire.





T(r0=0, C=3, D=7, P=20 )

T(r0=0, C=2, D=4, P=5 )

T(r0=0, C=1, D=8, P=10 )

0 2 5 7 20

20

20

5

5

5

0

0

6 8

6 8

4 9 10 12 14 15 17 192

12 13 1810




Ordonnancement Least Laxity (LL) : (1/4) [58/223]

Algorithmes en ligne à priorité variable : la priorité varie dans letemps.

La tâche de plus haute priorité à l’instant t est celle qui a la pluspetite laxité dynamique Li(t).Cet algorithme est optimal et les conditions d’ordonnançabilitédes tâches sont les mêmes que pour Earliest Deadline.

Les séquences produites par LL sont équivalentes à cellesproduites par ED lorsque les valeurs des laxités sont calculéesaux dates de réveil.

Par contre, si on calcule la laxité à chaque instant alors laséquence produite par LL entraîne plus de changements decontextes que par ED.





Les figures, qui se trouvent sur les transparents suivants,montrent l’ordonnancement avec LL pour les 3 tâches del’exemple sur ED, avec un calcul de laxité effectué aux seulesdates de réveil.

À t=0, les 3 tâches sont réveillées. Laxité dynamique deT1=7-3=4. Laxité de T2=4-2=2. Laxité de T3=8-1=7. C’est doncT2 (la + prioritaire) qui s’exécute à t=0 (pour 2 unités).

À t=2, c’est T1 qui s’exécute (sa laxité [7-2-3] est plus petite quecelle de T3 [8-2-1] ).

À t=5, T2 se réveille de nouveau. Sa laxité dynamique (9-5-2 =2ème échéance - temps courant - durée exécution) est égale à 2,celle de T3 (8-5-1) est de 2 également (retard ’toléré’ t.q.l’échéance est toujours respectée). On peut choisir T3 (cas a) ouT2 (cas b) pour être ordonnancée et s’exécuter.





T 1 (r0=0, C=3, D=7, P=20)

T 1 (r0=0, C=2, D=4, P=5)

T 1 (r0=0, C=1, D=8, P=10)

0 2 5 7 20

0 2 4 5 6 8 9 10 12 14 15 17 19 20

0 5 6 8 10 13 18 2012

tempstemps

temps

temps

FIG.: Ordonnancement “Least Laxity”. Cas (a) : c’est T3 qui est élue à t=5





T 1 (r0=0, C=3, D=7, P=20)

T 1 (r0=0, C=2, D=4, P=5)

T 1 (r0=0, C=1, D=8, P=10)

0 2 5 7 20

0 2 4 5 9 10 12 14 15 17 19 20

0 8 10 13 18 2012

tempstemps

temps

temps

7

7

FIG.: Ordonnancement “Least Laxity”. Cas (b) : c’est T2 qui est élue à t=5




Algorithmes pour les tâches apériodiques

But : les contraintes temporelles des tâches périodiques doivent êtrerespectées et :

(1) soit minimiser le temps de réponse des tâches apériodiques àcontraintes relatives Best Effort),

(2) soit maximiser le nombre de tâches apériodiques à contraintesstrictes qui respectent leurs CT .




Traitement en arrière-plan (Background Processing) (1/3) [63/223]

Tâches apériodiques à contraintes relatives arrière-plan,serveurs de tâches, ...

Les tâches apériodiques sont ordonnancées lorsque leprocesseur est oisif (pas de tâche périodique prête). Si ∃plusieurs tâches apériodiques, traitement par date de réveil(FIFO).

La figure du transparent suivant montre un tel ordonnancementsur un intervalle égale à 2 fois la période d’étude d’uneconfiguration de 2 tâches périodiques à échéances sur requêteT1(r0 = 0,C = 2,P = 5), T2(r0 = 0,C = 2,P = 10).L’application de ’Rate Monotonic’ à cette configuration laisse leprocesseur oisif sur les intervalles [4,5], [7,10], [14,15] et [17,20].




Traitement en arrière-plan (Background Processing) (2/3) [64/223]

La tâche apériodique Ta3(r = 4,C = 2) survenant à t = 4 peutimmédiatement commencer son exécution qu’elle finit sur letemps creux suivant c-à-d entre les temps t = 7 et t = 8.

La tâche apériodique Ta4 (r=10, C=1) qui survient à t=10 doitattendre le temps creux [14,15] pour s’exécuter.

La tâche apériodique Ta5 (r=11, C=2) doit attendre le tempscreux [17,20] pour s’exécuter.




Traitement en arrière-plan (3/3) [65/223]T1 (r0=0, C=2, P=5)

T1 (r0=0, C=2, P=10)

Temps creux

Taches apériodiques

Tap (r=4, C=2)Tap (r=10, C=1)

Tap (r=11, C=2)

0

0

0

0

2 5 7 10 12 15 17 20

20

20

20

2 4 10 12 14

4 5 7 10 14 15 17

4 5 7 8 14 15 17 1910 11

temps

temps

temps

temps




Tâches apériodiques à contraintes relativesarrière-plan, serveurs de tâches,... [66/223]

Remarque :La méthode d’ordonnancement en arrière-plan est simple, peucoûteuse et applicable ∀ l’algorithme d’ordonnancement des tâchespériodiques.Mais les temps de réponse des tâches apériodiques peuvent êtremauvais surtout si la charge des tâches périodiques est importante.




Les serveurs de tâches [67/223]

Un serveur est une tâche périodique créée spécialement pourveiller à l’ordonnancement des tâches apériodiques.Elle est caractérisée par une période et un temps d’exécution (lacapacité du serveur).Elle est souvent ordonnancée avec le même algorithme que lesautres tâches périodiques.Une fois active, la tâche serveur sert les tâches apériodiquesdans la limite de sa capacité.L’ordre de service des tâches apériodiques ne dépend pas del’algorithme d’ordonnancement des tâches périodiques (il peutêtre FIFO, fonction(échéances), fonction(temps d’exécution), ...).∃ plusieurs types de serveurs : le plus simple est le serveur parscrutation. Les autres (serveur ajournable, à échange de priorité,sporadique) en sont des améliorations.




Ord. “avec un serveur par scrutation” (1/4) [68/223]

À chaque activation, le serveur traite les tâches apériodiques enattente depuis son activation précédente, jusqu’à épuisement desa capacité (ou plus de tâches en attente).Si, lors d’une nouvelle activation, il n’y a aucune tâcheapériodique en attente, le serveur se suspend jusqu’à laprochaine occurrence : sa capacité (temps d’exécution) estrécupérée par les tâches périodiques.Transparent suivant : exemple de serveur par scrutation.Configuration :

2 tâches périodiques à échéances sur requête T1(r0=0, C=3,P=20) et T2(r0=0, C=2, P=20).La tâche serveur est Ts(r0=0, C=2, P=5) est de plus grandepriorité (car plus petite période) avec “Rate Monotonic” appliquépour ordonnancer les 3 tâches.On vérifie que la condition d’acceptabilité est remplie :3

20 + 210 + 2

5 = 0.75 ≤ 0.77





0

0

0

0

20

20

20

20

2 10 12 14

temps

temps

temps

temps

T1 (r0=0, C=3, P=20)

T2 (r0=0, C=2, P=10)

Tps (r0=0, C=2, P=5)

taches apériodiques

2 5

4 5 107

capacité du serveur

Tap1(r=4, c=2)Tap1(r=10, c=1) Tap1(r=11, c=2)

5 7 10 12 15 16

11 12 15 16

12





Commentaires :

À t=0, aucune tâche apériodique, donc le serveur se suspendimmédiatement. C’est T2 de priorité élevée suivante quis’exécute, puis c’est T1.

À t=4, la tâche apériodique Ta3 survient. Elle doit attendrel’occurrence suivante du serveur (t=5) pour s’exécuter. Elleépuise alors toute la capacité (C=2) du serveur.

À t=10, le serveur se réveille de nouveau, il sert la tâcheapériodique Ta4 qui vient d’être activée. Puis, il sert Ta5. La tâcheTa5 ne peut s’exécuter entièrement car elle épuise la capacitérestante du serveur.

Elle doit attendre l’occurrence suivante du serveur à t=15 pourfinir son exécution. Il reste encore une unité au serveur, il la perdcar il n’y a aucune tâche apériodique à servir.





Remarques :

Faiblesses : lorsque le serveur est prêt, si pas de tâches à traiter,sa capacité est perdue. Si des tâches apériodiques surviennent,elles doivent attendre l’occurrence suivante.

Amélioration : serveur “ajournable” : si pas de tâche apériodiqueà servir, le serveur prêt conserve sa capacité. Il est donc prêt àservir d’éventuelles tâches apériodiques qui surviennent. MAIS, ilviole le principe de “Rate Monotonic” (tâche prête de plus hautepriorité doit s’exécuter). Il diminue le taux d’utilisation duprocesseur par les tâches périodiques.




Ordonnancement “avec un serveur sporadique” (1/3) [72/223]

Il améliore le temps de réponse des tâches apériodiques sansdiminuer le taux d’utilisation du processeur des tâchespériodiques.

Ce serveur est également une tâche périodique de plus hautepriorité, qui conserve sa capacité de traitement si, à son réveil, iln’y a pas de tâche apériodique à servir.

Mais ici, le serveur sporadique ne retrouve pas sa capacitéinitiale à chaque occurrence.

La figure sur le transparent suivant montre le fonctionnement d’unserveur sporadique sur le même ensemble de tâches queprécédemment : T1(r0=0, C=3, P=20) et T2(r0=0, C=2, P=20). Latâche serveur est Ts(r0=0, C=2, P=5).

À t=0, le serveur se réveille, mais se suspend car pas de tâchesapériodique à traiter (mais il conserve sa capacité, 2).





À t=4, la tâche apériodique Ta3 survient. Elle est servieimmédiatement entre t=4 et t=6 et consomme toute sa capacité.Comme le serveur s’est exécuté, une date de réinitialisation desa capacité est calculée : ce sera t=4+5. La valeur deréinitialisation est 2.À t=9, le serveur retrouve toute sa capacité, mais il se suspendcar il n’y a pas de tâche apériodiques en attente.À t=10, la tâche Ta4 arrive et s’exécute tout de suite pendant uneunité (C=1). Puis Ta5 arrive et commence à s’exécuter pendantune unité et elle est suspendue jusqu’à nouvelle occurrence duserveur (car sa capacité est épuisée).Une nouvelle date de réinitialisation de la capacité est calculée :t=10+5. La tâche Ta5 poursuivra son exécution pour une unitéquand le serveur aura récupéré sa capacité à t=15.Il reste au serveur 1 unité qu’il récupérera à t=20.





0

0

0

0

20

20

20

20

2 10 12 14

temps

temps

temps

temps

T1 (r0=0, C=3, P=20)

T2 (r0=0, C=2, P=10)

Tps (r0=0, C=2, P=5)

taches apériodiques

2

4 10

capacité du serveur

Tap1(r=4, c=2)Tap1(r=10, c=1) Tap1(r=11, c=2)

11 12 15 16

4 6 7

6

1210012

96 15




Tâches apériodiques à contraintes strictes (1/2) [75/223]Une méthode consiste à doter les tâches apériodiques avec despseudo-périodes :

C’est l’intervalle minimal entre deux occurrences successivesd’une tâche apériodique.On utilise “RM” pour ordonnancer les 2 types de tâches.Difficulté : l’évaluation de la pseudo-période et la sous-utilisationdu processeur.

Une autre méthode :Les tâches apériodiques sont traitées sans hypothèse sur leurrythme d’arrivée.Elles sont ordonnancées selon “Earliest Deadline”.À chaque arrivée d’une tâche apériodique, une “routine” degarantie teste dynamiquement si la nouvelle tâche peut s’exécuteren respectant ses CT, celles des tâches périodiques et celles desautres tâches apériodiques précédemment acceptées mais nonterminées.Si le test est positif, la tâche est acceptée.




Tâches apériodiques à contraintes strictes (2/2) [76/223]

∃ 2 politiques d’acceptation dynamique de tâches apériodiques quifavorisent toutes les 2 les tâches périodiques, car les tâchesapériodiques génératrices de surcharge sont rejetées.Ces politiques sont applicables notamment sur un système réparti oùun mécanisme de partage de charge permet de faire exécuter unetâche rejetée sur un site par un autre site moins chargé.Ces 2 politiques sont :

Ordonnancement “ dans les temps creux”.

Ordonnancement “conjoint”.




Ordonnancement “dans les temps creux” (1/4) [77/223]

Acceptation dans les temps creux d’une séquence rigide detâches.Elle consiste à ordonnancer les tâches apériodiques dans lestemps creux de la séquence d’ordonnancement “ED” des tâchespériodiques.Proche de la politique en ’arrière-plan’ vue précédemment, maisici les tâches apériodiques ont des CT à respecter et sontelles-mêmes ordonnancées selon “ED”.À chaque réveil d’une tâche apériodique, la routine de garantie :

1. teste l’existence d’un temps creux suffisant pour l’exécution de latâche apériodique entre sa date de réveil et son échéance.

2. si ce temps creux existe, elle vérifie que l’acceptation de lanouvelle tâche ne remet pas en cause le respect des CT detâches apériodiques précédemment acceptées, non encoreachevées. Cette vérification ne concerne que les tâchesapériodiques dont les échéances sont ≥ à celle de la nouvelle.





Si au moins une des conditions 1 ou 2 n’est pas satisfaite, alors latâche est rejetée, sinon elle est ajoutée à l’ensemble des tâchesapériodiques acceptées, pour être exécutée selon son échéance.Exemple : La figure du transparent suivant montre que laconfiguration périodique “ED” présente durant la période d’étude3 intervalles de creux : [8,10], [13,15] et [17,20].

Les 3 tâches apériodiques Ta4, Ta5 et Ta6 peuvent être acceptéesdans ces temps creux : à t=4, Ta4 se réveille.Le temps creux existant entre sa date de réveil et son échéanceest l’intervalle [8,10] = 2 unités juste suffisantes pour exécuter latâche.Ta4 dispose donc d’assez de temps pour s’exécuter dans lerespect de ses CT, et comme il n’a pas d’autre tâchesapériodiques précédemment acceptées mais non terminée, elleest acceptée.




Ordonnancement “dans les temps creux” (3/4) [79/223]À t=10, Ta5 se réveille. Le temps creux existant entre sa date deréveil 10 et son échéance 18, est de 3 unités (tout l’intervalle[13,15] + 1 unité de l’intervalle [17,20]).Il y a donc d’assez de temps pour exécuter Ta5 qui a un tempsd’exécution égal à 1. Et comme il n’a pas de tâches apériodiquesacceptées et non terminées (Ta4 s’était exécutée entre 8 et 10),alors Ta5 peut être acceptée.À t=11, Ta6 se réveille. Le temps creux existant entre sa date deréveil 11 et sont échéance 16 est de 2 unités ([13,15]), donc justesuffisant pour l’exécuter dans le respect de son échéance.Mais, il faut vérifier que son acceptation ne remet pas en causeles CT des autres tâches apériodiques acceptées non terminées(et d’échéances plus éloignées que la sienne).Ici Ta5 qui n’a pas encore commencé son exécution et dontl’échéance est 18.L’ordre d’exécution devient Ta6 puis Ta5 et on constate quechacune peut s’exécuter dans le respect de ses CT (car C=2 pourTa6 et C=1 pour Ta5).





0

0

20

202

temps

temps

2 5

8

T1 (r0=0, C=3, D=7, P=20)

T1 (r0=0, C=2, D=4, P=5)

temps

0

7

4 5 6 9 10 12 14 1715 19

65 10 1812 13 208

T1 (r0=0, C=1, D=8, P=10)

8 10 13 15 17 20

temps creux

4 8 10 13 18 20

Tap1(r=4, c=2, d=10)

11 15 1716

taches aperiodiques

Tap2(r=10, c=1, d=18) Tap3(r=11, c=2, d=16)




Ordonnancement “conjoint” (1/4) [81/223]Acceptation des tâches apériodiques et ordonnancement conjointaux tâches périodiques.

À chaque arrivée d’une nouvelle tâche apériodique, il y aconstruction d’une nouvelle séquence “ED” comprenant à la foisles tâches périodiques, les tâches apériodiques précédemmentacceptées mais non terminées et la nouvelle tâche.

Si la séquence peut être construite, alors la tâche est acceptée.

Les figures sur les transparents suivants montrent un exemple defonctionnement et on voit que les 3 tâches apériodiques Ta4, Ta5

et Ta6 peuvent être ordonnancées conjointement aux tâchespériodiques.

À t=4, Ta4 se réveille. La séquence “ED” construite à t=4comprend les tâches périodiques actives T1(C(4)=1, d=7) et T3,les requêtes à venir des tâches périodiques ainsi que la tâche quiarrive Ta4.




Ordonnancement “conjoint” (2/4) [82/223]L’exécution de celle-ci sera planifiée entre t=8 et t=10. Laséquence respecte les CT de toutes les requêtes qui lacomposent.

À t=10, Ta5 se réveille. La séquence “ED” construite à t=10comprend les requêtes à venir des tâches périodiques T2 et T3 etcelle de Ta5. Ici aussi, la séquence “ED” permet le respect desCT de toutes les requêtes qui la composent. L’exécution de Ta5

acceptée est planifiée entre 13 et 14.

À t=11, Ta6 se réveille (figure suivante 2.12). La séquence “ED”construite à t=11 comprend les tâches périodiques activesT2(C(11)=1, d=14) et T3, les requêtes à venir de la tâchepériodique T2 ainsi que les tâches apériodiques Ta5 et Ta6. Latâche Ta6 peut être ordonnancée sans remettre en cause ni leséchéances des tâches périodiques, ni celle de la tâcheapériodique Ta5. Ta6 est donc acceptée.




Ordonnancement “conjoint” (3/4) [83/223]

0

0

20

202

temps

temps

2 5

8

T1 (r0=0, C=3, D=7, P=20)

T1 (r0=0, C=2, D=4, P=5)

temps

0

7

4 5 6 9 10 12 14 1715 19

65 10 1812 13 208

T1 (r0=0, C=1, D=8, P=10)

8 10 13 20

Tap4(r=4, c=2, d=10) Tap5(r=10, c=1, d=18)

taches aperiodiques

4

temps

14 18




Ordonnancement “conjoint” (4/4) [84/223]

��

0

0

20

202

temps

temps

2 5

8

T1 (r0=0, C=3, D=7, P=20)

T1 (r0=0, C=2, D=4, P=5)

temps

0

7

4 5 6 9 10 12 14 15 19

65 10 188

T1 (r0=0, C=1, D=8, P=10)

8 10

Tap4(r=4, c=2, d=10) Tap5(r=10, c=1, d=18)

taches aperiodiques

4

temps

14 18

1816

14 15

12 15 1611

Tap6(r=11, c=2, d=16)

20

20




Ordonnancement de tâches dépendantes (1/2) [85/223]

Contraintes de précédence : Ti → Tj si Tj doit attendre la fin del’exécution de Ti pour commencer son exécution.

Si A précède B alors {(1) rB ≥ rA, (2) si A périodique alors B l’estégalement et (3) priorité(A) > priorité (B)}Contraintes de précédence et ’Rate Monotonic’ : dans le cas del’ordonnancement selon “RM”, on transforme hors lignel’ensemble des tâches liées par une contrainte de précédence enun ens. de tâches indépendantes pour lesquelles le testd’acceptabilité de “RM” est valide, en faisant :

Le calcul des dates de réveil : r∗i = max{ri , r∗pred } avec r∗pred datede réveil de la tâche précédant la tache i .Si A et B ont la même période avec A qui précède B alors priorité(A) > priorité (B)




Ordonnancement de tâches dépendantes (2/2) [86/223]Contraintes de précédence et ’Earliest Deadline’ : la prise encompte de la précédence est réalisée en modifiant ri , di ,r∗i , d∗i ,selon les formules :

r∗i = max{ri , max(r∗pred + Cpred ) }, c-à-d la date de début d’unetâche doit être supérieure à toutes les dates de début de sesprédécesseurs immédiats augmentées de leurs duréesd’exécution.d∗i = min{di , min(d∗succ- Csucc) }, c-à-d pour une instance donnée,l’échéance d’une tâche doit être inférieure à toutes les échéancesde ses successeurs immédiats diminuées de leurs tempsd’exécution.

Tâches partageant des ressources critiques : problèmes.Évaluer le temps de réponse d’une tâche.Inversion de priorité : apparaît quand une tâche A est retardéepar une tâche moins prioritaire B (car A a demandé uneressource déjà détenue par C, moins prioritaire que A et B).Interblocage.




Protocoles prenant en compte les ressources partagées [87/223]

Héritage de priorité (PIP, Priority Inheritance Protocole) : résout leproblème d’inversion de priorité : la tâche en section critiquehérite de la plus haute priorité parmi celles des tâches en attente(bloquées). La durée de l’attente des tâches peut être très grande(car l’interblocage n’est pas résolu).

Priorité plafond (PCP, Priority Ceiling Protocol) : Limite la duréemaximale de blocage des tâches à la durée d’une section critiqueet prévient les interblocages (deadlock). L’idée est que chaqueressource se voit affectée une priorité égale à celle de la tâchede plus haute priorité qui va y accéder.




Ordonnancement conjoint : tâches et messages (1/3) [88/223]

Systèmes temps réel et répartis :Communication intra et inter sites.Envoi de messages.Problème : respecter les temps de transfert des messages enbornant les délais.

Un message peut être caractérisé par :sa criticité (criticality ) : ce sont les contraintes de temps associéesau messagesa longueur : nombre d’octets composant le message. Lesmessages sont transmis trame par trame sur le réseau. Lalongueur d’une trame = f(type de réseau)son type : synchrone, asynchroneson adresse de destination




Ordonnancement conjoint : tâches et messages (2/3) [89/223]Plusieurs protocoles sont définis, en fonction du type de réseau :

Réseau à commutation de paquets :Chaque station est reliée au réseau et ne connaît pas lesprotocoles utilisés pour communiquer à l’intérieur du réseau.La station établit une connexion selon un contrat lui garantissantune certaine QoS (taux de perte, délai max, ...).La station (considérée comme un abonné) s’adresse au nœud(commutateur ATM par exemple) auquel elle est raccordée, et lenœud se charge du transfert.Les stations ne rentrent pas en conflit.

Réseau à accès multiple :Les stations connectées au réseau contrôlent l’accès au réseauvia une technique MAC (Medium Access Control) implantée surchaque station.L’accès au médium est soit par compétition, soit par consultation(jeton).Les mécanismes d’ordonnancement des messages sontimplantées dans les stations (pour respecter les CT).




Ordonnancement conjoint : tâches et messages (3/3) [90/223]

Ordonnancement des messages : les techniquesd’ordonnancement sont adaptées de celles des tâches (ED, RMnotamment).

Pour ordonnancer les tâches, on doit connaître leurs tempsd’exécution.

Pour ordonnancer les messages, il faut connaître leurs temps detransmission. La durée de transmission est fonction de la taille dumessage, du débit et de la longueur du réseau, du format destrames réseau utilisées et du protocole.

Exemple : pour le bus à jeton, la durée de transmission d’unmessage de n octets est 96+8xn µ s (on considère que lesadresses sont codées sur 2 octets, un seul octet est utilisécomme information pour la trame, on néglige le délaiinter-trames. Le délai de transmission du jeton est 96 µ s)




Exemple : Bus à jeton [91/223]

Ensemble des stations = anneau logique.

Le droit d’émettre est réservé à une seule station : celle qui a lejeton.

Quand une station a le jeton, elle émet des trames pendant unedurée fixée, puis transmet le jeton.

Le bus à jeton peut fonctionner avec ou sans priorités.

Des paramètres sont utilisés : temps de possession du jeton, 3compteurs de rotation du jeton, notamment.

Avec tous ces éléments, des protocoles spécifiques sont définispour ordonnancer les tâches et les messages dans un systèmedistribué.


Rappel sur les Systèmes deGestion de Bases de Données


Historique des SGBD [93/223]Evolution : Fichiers isolés ⇒ gérés par des SGF (systèmes degestion de fichier).Problèmes :

redondance d’informations,incohérences introduites lors des mises à jour,absence d’exploitation des liens entre fichiers,une application et ses fichiers ⇒ liens étroits entre les données etles traitements sur ces données,...

⇒ Naissance du concept de base de données et des systèmes quiles gèrent : les SGBDObjectifs principaux : pallier les problèmes des SGF.

⇒ Les 2 premières générations de SGBD (fin des années 50 →années 70), les modèles hiérarchiques et réseaux.

⇒ Atténuent les problèmes de redondance, de non exploitation desliens, d’incohérence,... mais ils sont étroitement liés aux supportsphysiques.

⇒ L’indépendance données/traitements n’est pas assurée.Claude Duvallet - 93/223 Les SGBD temps réel

Les SGBD relationnels [94/223]

Naissance du concept de base de données relationnelle en 1970.

Les premiers SGBDR : fin des années 70.

Ces SGBD assurent l’indépendance données/traitements.

Avec leurs langages de manipulation (SQL et variantes),l’utilisateur manipulent la base en spécifiant ce qu’il veut (QUOI)et non COMMENT l’obtenir.

À leurs débuts : problèmes de performances. Avec, lesdifférentes optimisations que l’on peut effectuer, les SGBDR sesont généralisés.

Un des problèmes des SGBD est le contrôle de concurrence del’accès aux données par plusieurs transactions.

Une transaction : ensemble d’actions (lectures, écritures).


Les propriétés ACID des transactions [95/223]

Atomicité : toutes les actions de la transactions s’exécutent avecsuccès, ou pas du tout (principe du tout ou rien)

Cohérence : Une transaction (bien programmée) fait passer labase d’un état cohérent dans un autre état cohérent.

Isolation : pendant son exécution, chaque transaction est isoléedes autres transaction, c-à-d que ses effets sur la base nedeviennent visibles des autre transactions que lorsqu’elle effectuel’opération de validation (Commit).

Durabilité : une fois qu’une transaction a effectué son ’commit’,ses effets sur la base deviennent permanents, même si unincident survient juste après le commit (et que ce commit esteffectué en mémoire centrale, et le système n’a pas encore eu letemps d’écrire physiquement sur la base) : assurée grâce aujournal (log).


Sérialisabilité et contrôle de concurrence [96/223]

Pour s’assurer que des transactions qui s’exécutent de manièreentrelacées ne produisent pas des incohérences dans la BD, ilfaut que cette séquence d’opérations soit ’sérialisable’,c’est-à-dire qu’elle doit produire le même résultat sur la base quesi elles s’exécutaient séquentiellement (Ti → Tj ...).

Pour cela, des protocoles de CC sont définis : le principal est le2PL (verrouillage à 2 phases).Principe général du 2PL :

une transaction qui désire manipuler un objet de la base doitd’abord poser un verrou sur cet objet (2 principaux S et X).La transaction acquiert ainsi les verrous au fur et à mesure de sesbesoins.Lorsqu’elle a terminé (en général au Commit), elle libère tous sesverrous.


Autres aspects des SGBD [97/223]

Reprise après panne : erreur locale à la transaction, pannesystème, panne de support.

Optimisation des accès à la base.

Tailles des buffers qui résideront en mémoire centrale.

Données et une partie du dictionnaire à garder en mémoirecentrale et politiques de placement, remplacement,...Objectif d’un SGBD en termes de performances :

Minimiser la moyenne du temps de réponse des transactions.Donc, on ne se préoccupe pas des temps de réponse individuelsdes transactions.


Bilan [98/223]

Les STR se préoccupent de l’ordonnancementdes tâches pour favoriser les respect deséchéances (pour chaque tâche).

Les SGBD se préoccupent de la gestion efficacedes données, et de l’optimisation du temps deréponse moyen des transactions.


Les données temps réelLes transactions temps réel

Contrôle de concurrenceLes transactions temps réel

Les Systèmes de Gestion deBases de Données Temps

Réel




Les avantages des SGBD [100/223]

La gestion de données en quantité importante.

Le maintien de la cohérence de la base de données.

Un temps de réponse moyen pour l’ensemble des transactions.

La structuration et une gestion efficace des données.

La facilité de manipulation grâce aux langages d’interrogation.




Les avantages des systèmes temps réel [101/223]

La gestion des données temps réel.

La prise en compte des contraintes temporelles pour lestraintements.

Une gestion efficace au moyen des ordonnacements temps réel.

Le respect des échéances et des priorités.




Les applications actuelles [102/223]

Suivi de positions d’objets par satellites.

Pilotage d’usines automatisées.

Contrôle de procédés industriels.

Applications embarquées.

Commerce électronique

Applications multimédia

Applications mobiles, nomadisme.

Etc.




Caractéristiques de ces applications [103/223]

Elles doivent gérer des quantités de plus en plus importantes dedonnées.

Certaines données possède des durées de validité.

Les traitements (les actions) possèdent des contraintes de temps.

La répartitions des applications, des traitements est de plus enplus courante (parfois dans un environnement sans fils).




Conséquences [104/223]

Les systèmes doivent tenir compte :

du respect des contraintes temporelles (des données et destransactions),

du maintien de la cohérence des données,

de la répartition des données et/ou traitements.

⇒ Solution : des SGBD temps réel (et répartis).




Problèmes clefs [105/223]

Prise en compte du temps : accès aux données dans les temps.

Validité temporelle des données : utiliser les données durant leurintervalle de validité et assurer leurs mises à jour à temps.

Avoir des systèmes fiables : données disponibles dès qu’on en abesoin (même en situation de crise ou de surcharge) etrestauration temps réel en cas d’incident.

Respect des échéances pour les traitements (transactions).Minimiser le nombre de transactions qui ratent leurs échéances.

Qualité de service pour les BD multimédia : offrir un serviceacceptable même en cas de surcharge.

Problème de répartition des données et/ou des traitements.




Les principaux travaux sur les SGBDTR [106/223]

Contrôle de concurrence et ordonnancement des transactionstemps réel.

Gestion de qualité de service dans les SGBDTR ou commentaméliorer la robustesse des applications face à l’imprévisibilitédes demandes utilisateurs et/ou systèmes.

Distribution des transactions et de données temps réel. Validationdistribuées des transactions temps réel.

Méthodes employées pour la validation des travaux : simulationset/ou prototypes de recherche.




Résultats des travaux de recherche contradictoires [107/223]

des conditions de simulation très différentes.

utilisation de simulateur d’une part et de prototypes d’autre part.

pas de SGBD temps réel commercial, pas de standard.




Les données dans les SGBDTR [108/223]

Des données non temps réel : les données classiques que l’ontrouve dans les autres types de SGBD.Des données temps réel : elles possèdent un intervalle de validitéabsolu (une échéance au delà de laquelle elles sont inutilisables).

les données de base : ce sont des données issues de capteurs(température, pression, etc.), on dit aussi données sensorielles.les données dérivées : ce sont des données qui sont calculées àpartir d’une ou plusieurs données temps réel (de base oudérivées) et par conséquent leur validité est liée à la validité desdonnées dont elles dépendent.




Maintien de la cohérence des données au sein d’une base de donnéestemps réel [109/223]

Cohérence Logique (respect des contraintes d’intégritéclassiques).Exemple : 0 < age < 140, salaire > smic, ...Cohérence temporelle :

absolue : la donnée doit être utilisée durant sa durée de validitéabsolue (⇒ la BD doit refléter fidèlement l’état réel del’environnement).relative : certaines données doivent être cohérentes entre elles :être valides pendant le même intervalle de temps (exemple :température et pression).




Formalisation de la cohérence [110/223]

R = ensemble de cohérence relative = ensemble de données quidérivent une nouvelle donnée.

On associe à l’ensemble R une dvr (durée de validité relative) :Rdvr

Soit d = (valeur, dva, estampille) dans R.d est dite cohérente ssi :

d est cohérente logiquement (respect des C.I.).d est cohérente temporellement :

cohérence absolue : |inst_courant−dest | ≤ ddvacohérence relative : |dest −d ′est | ≤ Rdvrdest est la donnée estampiée (la valeur à l’instant de la saisie).




Exemple [111/223]

Températuredva = 5, pressiondva = 10

L’ensemble de validité relative R = température, pressionSoit Rdvr = 2 et instant_courant = 100 alors :

a) température = (valeur, dva, estampille) = (347, 5, 95) et pression =(50, 10, 97) sont cohérentes temporellement (absolue car |100-95|≤ 5 et |100-97| ≤ 10, et relative car |95-97| ≤ 2)

b) température = (347, 5, 95) et pression = (50, 10, 92)cohérence absolue : oui (car |100-95| ≤ 5 et |100-92| ≤ 10cohérence relative : non (|95 - 92| = 3 (donc > Rdvr = 2) ⇒ lesvaleurs de la température et de la pression ne sont pas saisiesdans l’intervalle toléré (≤ 2 secondes par exemple).




Les transactions temps réel [112/223]

Transactions à échéances strictes critiques (hard deadline) :Avionique, contrôle de centrales nucléaires,...Si une transaction rate son échéance ⇒ graves conséquences(humaines, économiques,...)

Transactions à échéances strictes non critiques (firm deadline) :Reconnaissance d’objets, commerce électronique,...Une transaction qui rate son échéance devient inutile (estabandonnée). Pas de conséquences graves

Transactions à échéances non strictes (soft deadline) :Multimédia,...Une transaction qui rate son échéance peut se poursuivre avecune QdS moindre.




Problèmes rencontrés [113/223]

Contrôle de concurrence de transactions,

Gestion des tampons (buffers),

Recouvrement en cas d’incident

Gestion des E/S,...

En tenant compte des contraintes temporelles

Propagation de contraintes : spécifications des contraintes⇒ échéances des transactions.

Problème principal :

la cohérence logique de la BD (respect des règles d’intégrité desdonnées)ET

la cohérence temporelle de la BD (respect des contraintestemporelles des transactions).




Respecter les contraintes [114/223]

Logiques :

Algorithmes de contrôle deconcurrence des transactions⇒ dérivés des algorithmespessimistes, optimistes,... deCC dans les SGBD

Temporelles :

Algorithmesd’ordonnancement destransactions⇒ dérivés des algorithmesd’ordonnancement destâches temps réel




Le protocole OCC-BCLe protocole CCALe protocole PCCAutres protocoles

Contrôle de concurrence dans les SGBD traditionnels [115/223]

Les algorithmes de contrôle de concurrence vont :

du plus pessimiste (2PL = verrouillage si conflit potentiel).

aux plus optimistes (pas de verrouillage. Si conflit réel alorsredémarrage de la transaction).

et d’autres (estampilles, versions,...).





Les algorithmes de contrôle de concurrence [116/223]Les algorithmes optimistes :

Détection des conflits le plus tard possible (à la validation destransactions).Optimiste : car l’hypothèse est qu’il existe une faible probabilitéque deux transactions accèdent à la même donnée au mêmemoment.

Les algorithmes pessimistes :Détection des conflits potentiels (si deux transactions s’exécutenten parallèle, l’algorithme agit comme si elles sont en conflits) ⇒utilisation du blocage.Pessimiste : car l’hypothèse est que deux transactions quis’exécutent en parallèle risquent de rentrer en conflit.

Autre type d’algorithme :Utilisent un mélange des deux techniques ou la techniqued’estampillage des transactions.





Dans les SGBD temps réel [117/223]

Les algorithmes de contrôle de conccurence et d’ordonnancement destransactions temps réel dérivent des deux types de techniquesprécédentes :

le contrôle de conccurence dans les SGBD,

et l’ordonnancement dans les systèmes temps réel.





Les principaux travaux [118/223]Les protocoles bloquants :

PCC : (Pessimistic Concurrency Control) abandon par priorité.Héritage de priorité.Héritage conditionnel de priorité.RW-PCP (Read-Write Priority Ceiling Protocol).

Les protocoles optimistes :OCC-BC-Opt-Wait (with Forward validation) (OptimisticConcurrency Control-Broadcast Commit).OCC-BC-Wait-50.OCC-BC-Opt-Sacrifice.CCA (COST CONSCIOUS APPROACH), une approche qui tientcompte du coût des transactions.

Autres protocoles :MCC : Multi-versions Concurrency Control.SCC : Speculative Concurrency Control.





Principe des protocoles optimistes [119/223]

Avec les protocoles optimistes ⇒ la transaction s’exécutejusqu’au point de commit.

Transaction = lecture, validation, écriture

validation en arrière-plan (backward) : validation par rapport auxtransactions déjà validées⇒ inutilisable dans le temps réel (car si un conflit survient, le seulchoix est de redémarrer la transaction en cours).

validation en avant-plan (forward) : par rapport aux transactionscourantes ⇒ utilisé dans le temps réel.





Le protocole OCC-BC OPT-Wait [120/223]Soit la transaction Tc en phase de validation.Si, avant sa validation, elle rentre en conflit avec T1, T2,...

cas 1 : si priorité (Tc) > priorité (Ti ) pour tout i ⇒ les Ti sontabandonnées.cas 2 : s’il existe des i tels que priorité (Ti ) > priorité(Tc) ⇒ Tc

attend la validation de toutes les Ti .

Avantages :cas 2 : Tc détient les ressources (et les garde) donc elle n’a pas àles redemander ⇒ améliore les performances du système.

Inconvénients :cas 2 : Tc détient les ressources ⇒ augmentation du nombre deconflits potentiels (si ces ressources sont demandées pard’autres transactions Ti ).cas 1 : les transactions Ti sont abandonnées et redémarrées.Elles ont donc moins de chances de se terminer avant leurséchéances (que si elles n’avaient pas été abandonnées).





Le protocole OCC-BC OPT-Wait [120/223]Soit la transaction Tc en phase de validation.Si, avant sa validation, elle rentre en conflit avec T1, T2,...

cas 1 : si priorité (Tc) > priorité (Ti ) pour tout i ⇒ les Ti sontabandonnées.cas 2 : s’il existe des i tels que priorité (Ti ) > priorité(Tc) ⇒ Tc

attend la validation de toutes les Ti .Avantages :

cas 2 : Tc détient les ressources (et les garde) donc elle n’a pas àles redemander ⇒ améliore les performances du système.

Inconvénients :cas 2 : Tc détient les ressources ⇒ augmentation du nombre deconflits potentiels (si ces ressources sont demandées pard’autres transactions Ti ).cas 1 : les transactions Ti sont abandonnées et redémarrées.Elles ont donc moins de chances de se terminer avant leurséchéances (que si elles n’avaient pas été abandonnées).





Le protocole OCC-BC Wait-50 [121/223]

Palie les problèmes de OCC-BC ⇒ un compromis=⇒ ajout d’un mécanisme du contrôle de l’attente.Modification du cas 2 de l’algorithme OPT-WAIT :

Tc doit attendre tant que plus de 50% des transactions aveclesquelles elle est en conflit aient des priorités supérieures à lasienne.Une fois ce seuil atteint ⇒ les Ti restantes sont abandonnées etredémarrées.

On peut aussi construire des variantes du type Wait-X avec X unpourcentage quelconque.





Le protocole OCC-BC OPT-SACRIFICE [122/223]

Résolution de conflit dirigée par « l’abandon par priorité ».

Soit Tc en phase de validation. Si, avant sa validation, elle rentre enconflit avec T1, T2,... alors :

cas 1 : si priorité (Tc) > priorité (Ti ) pour tout i ⇒ les Ti sontabandonnées.

cas 2 : s’il existe des i tels que priorité (Ti ) > priorité (Tc) ⇒ Tc

est abandonnée et redémarrée (elle se sacrifie).





Le protocole Cost Conscious Approach [123/223]

Améliore :

EDF-HP (High Priority) qui utilise seulement l’échéance pourdécider de la transaction à exécuter.ET

EDF-CR (Conditional restart) qui utilise l’échéance et le tempsd’exécution restant estimé⇒ pourrait permettre à une transaction non prioritaire determiner (si elle ne fait pas rater leurs échéances auxtransactions de plus hautes priorités).S’il reste peu de temps à une transaction pour se terminer, mêmesi elle n’est pas prioritaire, elle est autorisée à poursuivre.





Principe du protocole Cost Conscious Approach [124/223]

Il effectue une préanalyse des transactions ⇒ connaissance desdonnées accédées en fonction des chemins d’exécution.Exemple :

Transaction A :

Accéder à W.Si (W > 100) alors

accéder à P, X, Y, ZSi P > 0 {

alors accéder à Rsinon accéder à S

}Sinon accéder à Q

Si Q > 0 {alors accéder à Rsinon accéder à S

}

Transaction B :

Accéder à X, Y, Z.





Le protocole PCC : Abandon par priorité [125/223]

Consiste à abandonner la transaction de plus basse prioritéquand le phénomène d’inversion de priorité2 survient. Parconséquent, les transactions à hautes priorités ne sont jamaisretardées par des transactions de plus basses priorités.

Si Ta demande un verrou sur un objet, détenu par destransactions de plus faibles priorités en mode conflictuel (W/R,R/W ou W/W) ⇒ celles-ci sont abandonnées et Ta acquiert leverrou.

Si priorité(Ta) < priorités(autres transactions en conflit) ⇒ Ta

attend que l’objet soit libéré (algorithme 2PL classique).

2une transaction de plus haute priorité A est bloquée par une transaction B de plusbasse priorité car B requiert une ressource déjà détenue par C.





Avantages et inconvénients du protocole PCC [126/223]

il assure que les transactions urgentes (de plus haute priorité) seterminent dans les temps.MAIS

des transactions peuvent être abandonnées à cause d’unetransaction de plus haute priorité, qui, plus tard, peut ne pas seterminer dans les temps.=⇒ travail inutile.





Héritage de priorités [127/223]

À chaque fois qu’une transaction se met en attente derrière unetransaction de plus basse priorité, détentrice du verrou, elle voitsa priorité promue au niveau de celle de la transactiondemandeuse, jusqu’à terminaison et libération du verrou.

Avantage : les transactions de basse priorité pourraient seterminer plus tôt (réduisant ainsi le temps d’attente destransactions de plus haute priorité).

Inconvénient : temps de blocage imprévisible, blocages chaînés(transactions de haute priorités en attente, plusieurs fois, derrièredes transactions de plus basses priorités).





Héritage conditionnel de priorités [128/223]

Variante du protocole d’héritage de priorité.

une transaction de faible priorité qui détient un verrou n’hérited’une plus haute priorité que si elle est « proche » de saterminaison, sinon elle est abandonnée.Avantages :

si elle est abandonnée, pas beaucoup de travail perdu car elle estloin de sa terminaison.délai d’attente réduits pour les transactions à haute priorité (carnon bloquées par des transactions de faible priorité loin de leurterminaison)





RW-PCP [129/223]

ordonnancement RM + modular CC protocol.Hypothèses :

BD ⇒ ensembles atomiques de données disjoints (EAD)cohérence d’un EAD : indépendamment des autrescohérence des EAD ⇒ cohérence de la BDModèle de tâche tel que :1 tâche = opérations non_BD + opérations_BD⇒ des tâches élémentaires et des transactions élémentaires.




Surdimensionnement des ressourcesRelaxation des propriétés ACID

Les transactions dans les SGBD classiques [130/223]

Les propriétés ACID :

Atomicité : principe du "Tout ou Rien". La transaction s’exécuteentièrement ou pas du tout.

Cohérence : la base de données doit rester cohérente.

Isolation : une transaction ne "voit" pas les effets d’autrestransactions (jusqu’à validation).

Durabilité : les effets d’une transaction validée deviennentpermanents dans la BD (même si un problème survient).





Les transactions dans les SGBD temps réel [131/223]

Il est souvent difficile de respecter les contraintes logiques ET lescontraintes temporelles.=⇒ quelques pistes de recherche :

Surdimensionement des ressources.Relaxation des propriétés ACID ;





Le surdimensionnement des ressources [132/223]

Dupliquer certains éléments matériels.

Dupliquer certains éléments logiciels (exemple les transactions).

Mettre en place des algorithmes adéquats.

⇒ Solution onéreuse. Exemple : le protocole SCC.





Relaxation des propriétés ACID [133/223]

Similarité des données.

Retard forcé (attente forcée).

Epsilon sérialisabilité.





Similarité des données [134/223]

T1 lit Xi (i-ème version de X) mais l’échéance de Xi expire avantque T1 ne valide.

T1 n’est pas abandonnée mais poursuit exécution avec la versionXi (Condition : Xi similaire Xi+1).

On augmente les chances que T1 respecte son échéance.Le protocole Similarity Stack Protocol (SSP) :

Nouveau critère de correction : epsilon-sérialisabilitéDans l’application : chaque objet a une borne de similarité.oi et oj similaires ⇐⇒ |estampille(oi )-estampille(oj )| <borne-similarité (o).





Attente forcée [135/223]

T1 lit Xi (i-ème version de X) mais l’échéance de Xi expire avantque T1 ne valide.

T1 n’est pas abandonnée, elle est mise en attente jusqu’àl’occurrence de la version Xi+1

Condition : connaître a priori le temps d’exécution ou le tempsrestant à la transaction pour se terminer





Epsilon sérialisabilité [136/223]

critère plus souple de correction des transactions.

quand epsilon = 0, ce critère devient la sérialisabilité classique.l’epsilon-sérialisabilité tolère :

qu’une transaction d’interrogation importe une quantitéd’incohérence,qu’une transaction d’écriture exporte une quantité d’incohérence

Des algorithmes de contrôle de divergence sont conçus, pourborner ces incohérences.


La validation des transactionstemps réel distribuées


Principe d’une transaction distribuée [138/223]

Une transaction s’exécute sur plusieurs sites qui communiquententre eux pour la validation finale.Le site initiateur de la transaction est le coordinateur. Les autressites sont des sites participants.Le coordinateur connait le nom de tous les participants et peutdonc leur envoyer des messages.Les participants connaissent le nom du coordinateur mais pasnécessairement le nom des autres participants.Chaque site contient un log de transaction distribuée sur supportstable où des informations sont enregistrées. Les log doiventsurvivre aux pannes.Un protocole de Validation Atomique (ACP) est un algorithmepour le coordinateur et les participants tels que le coordinateur ettous les participants valident la transaction ou bien tousl’abandonnent.


Validation atomique d’une transaction distribuée : conditions [139/223]

Tous les sites participants qui atteignent une décision, atteignentla même décision.Un site participant ne peut pas inverser sa décision une fois prise.La décision de commiter peut être prise seulement si tous lessites votent OUI (si un seul site vote NON, il est en droit de faireun Abort à tout moment. Après avoir voté OUI, il est dans unepériode d’incertitude jusqu’à la décision finale du coordinateur).En l’absence de pannes et si tous les process votent OUI, alorsla décision est "Commit".Considérons toute exécution contenant seulement des pannesque l’algorithme peut tolérer. Si toutes les pannes survenues sontréparées et si aucune nouvelle panne ne survient, alors tous lessites pourront atteindre une décision par la suite.

=⇒ Le plus simple et populaire des protocoles de validation atomiqueest le 2PC. Puis, il y a PA, PC, 3PC,...


Validation atomique d’une transaction distribuée : scénario de pannes(1/2) [140/223]

1. Une panne coupe la communication entre un site p et les autrespendant que p est incertain (durant sa période d’incertitude) :p ne peut atteindre une décision qu’après que la communicationsoit rétablie. Le processus est bloqué.⇒ Une panne de communication peut engendrer un blocage d’unprocessus pour une période indéterminée.


Validation atomique d’une transaction distribuée : scénario de pannes(2/2) [141/223]

2. Le site p tombe en panne pendant sa période d’incertitude :

p est ensuite restauré (recover) mais il ne peut pas atteindre unedécision tout seul (independant recovery).p doit communiquer avec les autres sites pour savoir quelle étaitla décision.

⇒ L’impossibilité de recouvrement indépendant en conjonction avecla panne totale (tous les sites) engendre des blocages :

Hypothèse Supposons que le site p soit le premier à recouvrir (revenir de lapanne totale).Comme p est incertain, il doit communiquer avec les autres sitesavant de pouvoir prendre une décision. Mais il ne peut pascommuniquer car ils sont tous en panne ⇒ blocage.

=⇒ Les pannes durant la période d’incertitude des sites posent degros problèmes.


Validation atomique : observations [142/223]

1 Si des pannes de communication ou des pannes totales sontpossibles, alors tout protocole de validation atomique (ACP) peutengendrer un blocage de processus.(Remarque : s’il s’agit uniquement d’une panne de site, il existedes ACP qui n’engendrent pas de blocages).

2 Aucun ACP ne garantit le recouvrement indépendant de sites enpanne.


Protocoles de contrôle de concurrence dans les SGBDdistribués [143/223]

2 PC (Two Phase-Commit).

PA (Presumed Abort).

PC (Presumed Commit).

3 PC (Three Phase-Commit).

Modèle utilisé :

un processus maître (coordinateur) qui s’exécute sur le site où latransaction est soumise

d’autres processus (participants) qui s’exécutent sur les sitescontenant les données auxquelles accède cette transaction.


Problématique et définitionsQualité de service

Une approche basée sur QdSMulti-Versions Data-FCSA

La gestion de la qualité deservice dans les SGBD temps

réel




Plan de la présentation [145/223]

Introduction et contexte.Quelques définitions.

Qualité de Service (QdS, QoS),Qualité des Données (QdD, QoD),Qualité des Transactions (QdT, QoT).

Problématique.

Spécification de la qualité de service dans les SGBDTR.

Le contrôle de la qualité de service.

Conclusion et problèmes de recherche.




Introduction et contexte [146/223]

Les applications informatiques rendent des services auxutilisateurs.

Sophistication des applications (production, serveurs Web,commerce électronique, etc.) en terme des données requises.

Répondre aux requêtes des utilisateurs avant échéance et enutilisant des données récentes.

⇒ accroissement des demandes de services de données tempsréel, utilisation de SGBD temps réel.

La charge des bases de données est imprévisible et peut devenirtrès vite importante (surcharge du SGBDTR).

⇒ Dépassement des échéances et utilisation de données nonrécentes durant ces phases de surcharge.




Objectifs [147/223]

Utiliser une approche basée sur la qualité de service pourgarantir des exigences sur le comportement des BD même encas de surcharge.

Important pour les applications reposant sur une exécution destransactions en temps réel et où il n’est pas possible d’avoir uneanalyse précise des arrivées et des temps d’exécution.Une première approche :

utilisation de techniques du calculs imprécis : faire un compromissur les ressources nécessaires pour obtenir la qualité de servicerequise.imprécision sur les données (QdD) et sur les transactions (QdT)afin de fournir la qualité de service demandée.

⇒ utilisation d’algorithmes d’équilibrage de charge dynamiques.




Les algorithmes d’équilibrage de charges [148/223]

Exemples : FCS-IC-1, FCS-IC-2.

Objectif : contrôler le comportement d’un SGBDTR même enprésence de variation de la charge et d’estimations imprécisesdes temps de calculs.Dans Amirijoo et al. :

ensemble d’expérimentations pour évaluer les performances deces algorithmes.simulations avec un grand nombre de cas de surcharge et detemps d’exécution estimé pour modéliser les imprévisibilitéspotentielles.

⇒ comportement robuste et contrôlé des SGBDTR en termes dequalité des transactions et des données même en phase desurcharges et lorsque les temps d’exécution estimés sontimprécis.méthodes utilisées pour prouver l’amélioration : comparaison avecdes algorithmes de base.




Quelques définitions (1/2) [149/223]

Données non temporelles :Ce sont les données classiques des applications informatiques.

Données temporelles :Ce sont des données qui possèdent une durée de vie limitée audelà de laquelle elles deviennent obsolètes (non fraîches). Leurdurée de vie correspond le plus souvent à la périodicité aveclaquelle elles sont mises à jour.

Transactions de mise-à-jour :Ce sont des transactions (en générale périodiques) qui mettent àjour des données de la base à partir de valeurs recueillies depuisdes capteurs.




Quelques définitions (2/2) [150/223]

Transactions utilisateurs :Elles correspondent aux transactions effectuées par lesutilisateurs, c’est-à-dire des demandes d’information oud’opérations sur les données. Elles se caractérisent à la fois pardes opérations de lecture mais aussi d’écriture dans la base dedonnées.

Qualité des données :Elle correspond à la précision ou l’erreur constatée sur la valeurstockée par rapport à la valeur réelle.

Qualité des transactions :Elle correspond à la précision du résultat fourni par la transactionpar rapport à une précision optimale obtenue lors d’un calculcomplet.




Qualité de service : définition [151/223]

Mesure collective du niveau de service fourni au client. La QdS peutêtre caractérisée par différents critères de performances de base quiincluent la disponibilité, le taux d’erreurs, le temps de réponse, le tauxde transactions réussies avant échéances, etc.




Les paramètres de la qualité de service [152/223]Paramètres temporels :

temps de transfert, temps de réponse, temps d’établissementd’une connexion.

Paramètres volumiques :quantité de données qu’une application souhaite transmettre parunité de temps.

Paramètres d’erreurs :pertes de paquets, livraisons tardives ou désordonnées despaquets, erreur d’établissement ou de fermeture de connexion.

Paramètres de fiabilité :la disponibilité et la tolérance aux fautes.

Paramètres de sécurité :degré de protection, de contrôle d’accès, authentification etconfidentialité.

Paramètres de coûts :le prix que l’utilisateur est prêt à supporter pour obtenir la qualitéde service demandée.




Spécification de la qualité de service [153/223]

Effectuée par le DBA à l’aide de paramètres.Trois manières possibles d’exprimer ces paramètres :

Approche déterministe : les paramètres sont exprimés au moyende valeurs ou d’intervalles de valeurs précis.Approche probabiliste : la qualité de service doit être respectéeselon une certaine probabilité ⇒ une plus grande flexibilité.Approche stochastique : l’utilisateur spécifie un ensembled’événements qui sont liés à la satisfaction de la qualité deservice de façon à ce qu’elle soit conforme à une certainedistribution stochastique.

Les valeurs de la qualité de service varient d’un domained’application à un autre.




Point de départ [154/223]

Des données temporelles mises à jour par des transactions demise à jour.

Des transactions utilisateurs effectuant des opérations complexesde lecture/écriture.

Imprécision sur les données et sur les transactions utilisateurs.

La qualité des données augmente au fur et à mesure quel’imprécision sur les données décroît.

La qualité des transactions augmente au fur et à mesure quel’imprécision des résultats produits par les transactions décroît.

La qualité des transactions utilisateur est liée à la qualité desdonnées (si la qualité des données décroît alors la qualité desrésultats fournis par les transactions décroît).




Problématique [155/223]

Hypothèse : indépendance entre la qualité des transactionsutilisateurs et la qualité des données.

Spécification du niveau de qualité désiré en termes d’état stableet d’état de surcharge du comportement des données et destransactions utilisateurs.

Objectif : adapter le comportement du SGBDTR afin de satisfaireune qualité de service spécifiée.

Fixer les paramètres de la qualité de service.

Comment respecter ou adapter ces paramètres pour obtenir unestabilité du comportement du SGBDTR même lorsque la chargedevient très importante.




Solution envisagée (1/2) [156/223]

L’approche utilisée :Répartir la charge entre les transactions de mise à jour et lestransactions utilisateurs.

⇒ Diminuer la charge des transactions utilisateurs amène àaugmenter les ressources disponibles pour les transactions demise à jour.

⇒ Diminuer la charge des transactions de mise à jour provoque uneaugmentation de la qualité des transactions "utilisateur".

Imprécision des données :admettre un certain écart entre la donnée stockée dans la base etsa valeur dans le monde réel,si un tel écart peut-être toléré alors on peut ignorer certainestransactions de mise à jour,la mesure de la qualité s’effectue au moyen de la notion d’erreursur la donnée (DE = Data Error).




Solution envisagée (2/2) [157/223]

Imprécision des données (suite) :soit di un objet et Tj une transaction mettant à jour di .l’erreur sur la donnée di est nommée DEi . C’est une fonction de lavaleur courante de la donnée (CurrentValuei ) de di et de la valeurmise à jour (UpdateValuej ) par la dernière transaction de mise àjour Tj .DEi = Φ(CurrentValuei ,UpdateValuej).l’erreur sur la donnée d’un objet donne une indication sur ladéviation de la valeur stockée par rapport à sa valeurcorrespondante dans le monde réel et qui a été mise à jour par ladernière transaction arrivée.ajustement de la charge de la mise à jour en fonction de l’erreursur la donnée manipulée (prise en compte de la marge supérieurede la déviation).marge supérieure donnée par MDE (Maximum Data Error).




Problématique du rejet des transactions de mise à jour [158/223]

Rejet ou pas rejet ?Tj rejetée si l’erreur sur la donnée (di ) qui doit être mise à jour parTj est ≤ à MDE (DEi ≤MDE).Tj exécutée et commitée si DEi > MDE .

Conséquences des changements de valeur de MDE :MDE ↗⇒ plus de transactions rejetées (erreur sur la donnéeplus grande et donc une qualité de donnée moins bonne).MDE ↘⇒ moins de transactions rejetées (erreur sur la donnéeplus faible et donc une qualité de donnée accrue).

Objectif : concevoir des algorithmes pour ajuster l’erreur sur ladonnée de telle façon que la qualité des données et destransactions utilisateurs satisfasse la qualité de service spécifiée.




Modèles utilisés (données, bases de données) [159/223]

Modèle de bases de données :SGBDTR avec contraintes strictes non critiques (firm),SGBD en mémoire principale.

Modèle de données et gestion des données :données temporelles et non temporelles,données temporelles : données de base représentant le monderéel et acquises par des capteurs,une donnée de base di est considérée comme temporellementinconsistante ou obsolète si on a dépassé l’estampille de diaugmentée de l’intervalle validité absolue de di (AVIi ) :

CurrentTime > Timestampi + AVIi

DEi = 100×|CurrentValuei −UpdateValuej |

|CurrentValuei |




Modèle de transaction (1/3) [160/223]

Transactions de mise à jour (MAJ) et transactions utilisateur :MAJ : transactions périodiques écrivant des données temporelles,Utilisateurs : transactions apériodiques lisant des objets temporelset lisant/écrivant des objets non temporels.

Une transaction Ti est composée :d’une sous-transaction obligatoire Mi ,de #Oi sous-transactions optionnelles, notée Oi,j où 1 ≤ j ≤ #Oi

ti ∈ {Mi , Oi,j , ... ,Oi,#Oi }

Décomposition des transactions effectuée selon l’approche deMilestone

les transactions peuvent fournir des résultats imprécis dont laprécision augmentera en fonction du nombre de sous-transactionsoptionnelles exécutées.





Une sous-transaction obligatoire est dite complète si elle l’estdans le sens traditionnel (terminée avant son échéance).

Les sous-transactions optionnelles dépendent de lasous-transaction obligatoire et sont exécutées uniquement s’ilreste du temps.

Mi ≺ Oi,1 ≺ Oi,2 ... ≺ Oi,#Oi

Toutes les sous-transactions possèdent l’échéance de latransaction principale :

Une sous-transaction est terminée si elle est complète ou amanqué son échéance.Une transaction (Ti ) est complète si sa sous-transactionobligatoire est terminée.Une transaction (Ti ) est terminée lorsque sa dernièresous-transaction optionnelle est terminée.





Une transaction de màj n’a pas de sous-transactions optionnelles.

Une transaction de màj est composée uniquement d’unesous-transaction obligatoire car elle n’effectue pas d’opérationcomplexe et possède un temps d’exécution plus faible que lestransactions utilisateur.

L’estimation du temps moyen d’exécution des transactions estconnue mais pas le temps courant, car on se situe dans unmodèle où l’utilisation du processeur est imprévisible et inconnuede l’ordonnanceur.




L’approche utilisée (1/2) [163/223]

Objectifs et méthodes :Gérer les performances du SGBDTR en termes de qualité destransactions et des données.Définir la qualité de service et la manière de la spécifier.Les algorithmes FCS-IC-1 et FCS-IC-2.

Règles de mesure des performances et spécification de QdS :Pourcentage de sous-transactions obligatoires ratant leuréchéance.

MM = 100 × #DeadlineMissM

#TerminatedM (%) [163/223]

Pourcentage de sous-transactions optionnelles ratant leuréchéance.

MO = 100 × #DeadlineMissO

#TerminatedO (%) [163/223]

MDE : l’erreur maximum tolérée sur les données.Mp est le pire cas de performance d’exécution dans un étattemporaire.




L’approche utilisée (2/2) [164/223]

Ts est le temps passé dans l’état précédent avant de revenir à unétat stable.U : la borne inférieure pour l’utilisation du système.

La qualité de donnée (QdD) est définie en termes de MDE : uneaugmentation de la qualité de données correspond à unediminution de MDE et vice versa.

On mesure la qualité des transactions en termes de pourcentagede sous-transactions qui ont raté leur échéance.




La spécification de la QdS [165/223]

Elle se fait par des valeurs références par rapport à MM , MO ,MDE, etc.

Exemple :Mr

M = 1% (i.e. référence MM )Mr

O = 10% (i.e. référence MO)MDEr = 2% (i.e. référence MDE)U ≤ 80%, Ts ≤ 60s et Mp ≤ 10%⇒MM ≤Mr

M × (Mp + 100) = 1.3%, MO ≤ 13% et MDE ≤ 2.6%




Qualité des transactions et imprécision des résultats [166/223]Objectifs :

augmenter la disponibilité des ressources,favoriser le respect des échéances au détriment de la qualité desrésultats,permettre au plus grand nombre de transactions de pouvoirs’exécuter.

Méthode employée :concevoir des transactions qui sont en mesure de fournir desrésultats intermédiaires exploitables,avoir recours à des algorithmes qui calcule des résultats imprécismais plus rapidement,augmenter la précision d’un résultat au fur et à mesure du temps.

Remarques :la qualité des résultats est une fonction qui prend en entrée leparamètre temps,plus une transaction dispose de temps, meilleure sera la qualitéde ses résultats.




Une architecture d’ordonnancement avec retour d’expérience

Moniteur

UUnouveau

....Source1

Sourcem

....Flux

Fluxm

1

Contrôleur d’utilisation et d’échéance ratées

Contrôleurde précision

Gestionnairede QdD

FM CC BSDéclencheur de transactions

Contrôleurd’admission

MDE

PourcentageMDETransactions Utilisateur

Transactions de MàJ

d’échéances ratées

Envoyées

Taux d’utilisation du CPU

Pourcentage d’échéances ratées

Fraîcheur

Abandon/Redémarre/Suspend

Bloquée

File des prêtes




Le gestionnaire de transactions (1/4) [168/223]

Le déclencheur de transaction est constitué :d’un gestionnaire de fraîcheur (FM) qui vérifie la fraîcheur desdonnées avant d’y accéder en utilisant l’estampille et l’intervallede validité absolue : il bloque les transactions qui désirent accéderà des données non fraîches,d’un gestionnaire de contrôle de concurrence (CC) qui est2PL-HP,d’un ordonnanceur de base (BS) qui est souvent EDF.

Deux files pour les transactions :les transactions de mise à jour et les sous-transactions(utilisateurs) obligatoires sont mises dans la file de priorité plusforte,les sous-transactions (utilisateurs) optionnelles sont mises dans lafile de priorité plus faible,la prise en compte des transactions de ces deux files est décidéeau niveau du déclencheur de transactions.





Le contrôle d’admission des transactions (AC) :il contrôle le flux des transactions entrantes,il décide si une transaction peut-être admise ou non dans lesystème,il utilise des paramètres tels que l’importance des transactions(priorité), la charge du système (utilisation des ressources), etc.

Le gestionnaire de précision :il écarte les transactions de mise à jour lorsqu’elles tententd’écrire une donnée (di ) possédant une erreur DEi ≤MDE ,sinon la nouvelle valeur de di est mise à jour,dans tous les cas l’estampille de di est mise à jour,son objectif est de faire diminuer la charge du système en termesd’exécution des transactions de màj,il augmente ou diminue la valeur de MDE en fonction du ∆Urenvoyé par le contrôleur d’utilisation.





Le moniteur :il mesure le nombre de transactions qui s’exécutent, qui seterminent avant leur échéance ou qui ratent leur échéance,il prend ces mesures auprès du déclencheur de transactions,il transmet les mesures qu’il a effectuées au contrôleurd’utilisation.

Le contrôleur d’utilisation :il dispose des renseignements qui lui sont fournis par le moniteur,il effectue un calcul d’utilisation du système qui lui permet dedétecter des phases de surcharge (trop grand nombre detransactions qui ratent leur échéance, par exemple),il regarde aussi la charge CPU du système,il effectue un calcul final lui permettant de déterminer ∆U(Différence entre l’utilisation réelle et la valeur de référence) quipourra influer sur le gestionnaire de qualité des données.





Le gestionnaire de qualité des données :il va augmenter ou diminuer la qualité des données en fonction del’utilisation du système (en phase surcharge, il diminuera la qualitédes données),il influe sur les transactions admises dans le système par lecontrôleur d’admission mais aussi sur l’exécution ou non destransactions de màj,il recalcule MDE afin de diminuer ou d’augmenter le nombre detransactions de màj qui s’exécutent,il calcule un nouveau ∆U à partir de celui fourni par le contrôleurd’utilisation et de ses propres changements internes,la nouvelle valeur de ∆U est transmise au contrôleur d’admission.




FCS et QdS : conclusion [172/223]

Prendre en entrée les paramètres de qualité de service spécifiéspar le DBA.

Recalculer les paramètres de la qualité de service en fonction del’exécution et du fonctionnement du système et en fonction desparamètres de référence.

⇒ Constitution d’une boucle de rétroaction dans les SGBD tempsréel pour contrôler le comportement des SGBDTR lors desphases de surcharge du système.

⇒ Il n’est pas nécessaire d’avoir un modèle précis de la charge dusystème.

⇒ On aboutit à une stabilisation dynamique du système en fonctionde la charge et des ressources disponibles.




ArchitectureSimulationsApports de MVD-FCSA

Avantages et inconvénients du modèle FCSA [173/223]

Avantages

permet d’obtenir un comportement contrôlé des SGBDTR.

fournit une garantie de qualité de service.

Inconvénientslorsqu’une transaction avec une forte priorité accède une donnéetoutes les transactions avec une priorité plus faible sont bloquées.

le gestionnaire de fraîcheur bloque les transactions "utilisateur"dont les données demandées sont obsolètes.

ceci rallonge le temps d’exécution des transactions et peut lesamener à manquer leur échéance.

Pour résoudre ce problème et diminuer ce risque, une nouvelle versionde l’architecture FCSA a été proposée, basée sur l’utilisation dedonnées multi-version : MVD-FCSA.





Feedback Control Scheduling Architecture [174/223]

Moniteur

UUnouveau

....Source1

Sourcem

....Flux

Fluxm

1

Contrôleur

de précision

Gestionnaire

de QdD

Contrôleur

d’admission

MDE

PourcentageMDETransactions Utilisateur

Transactions de MàJ

d’échéances ratées

Envoi



Fraîcheur

Bloquée

Abandon

Redémarrage/Suspension

Déclencheur de transactions

Contrôleur d’utilisation et d’échéances ratées

FM CC BSFile des transactionsprêtes





Une gestion multi-versions des données temps réel [175/223]

ConcurrenceContrôleurContrôleur

d’échéanceFraîcheur

des données

File d’attente des transactionsprêtes à être exécutées

Ordonnanceur

MDE

V1

V2

V3

V1

V2

V3

V1

V2

V3

.........

Gestionnaire de données temps réel

Donnée Donnée Donnée

.....

.....

.....

Déclencheurde transactions

Accès aux données temps réel

Abandon/ Redémarrage/

Terminaison

ExécutionEnvoi

File des transactionsbloquées

Suspension

Abandon





3 approches possibles pour l’architecture MVD-FCSA (1/3) [176/223]

Approche no1 : un nombre fixe de versions

Toutes les valeurs des données pondent à différentes versiond’une même donnée.

Le nombre maximum de version est limité. Cette limitation estfixée par avance par le DBA en accord avec le niveau de qualitéde service requis.






Approche no2 : le nombre de versions est dynamiquement ajusté

Le nombre de versions d’une donnée est ajusté dynamiquementen fonction des besoins.

Pour chaque donnée, une file des versions est maintenue.

Cette file est continuellement mise à jour afin de limiter le nombrede versions présentes.

Des versions sont ajoutées ou supprimées en fonction de lafraîcheur des données et de la valeur du paramètre MDE.






Approche no3 : une approche mixte

On combine les deux approches précédentes : on ajustedynamiquement le nombre de données multi-version tout en nedépassant pas un seuil fixé à l’avance pour le nombre deversions.

On considère aussi un seuil pour la taille de la base de données.

Une nouvelle version de données ne pourra être ajoutée que sielle ne provoque pas le dépassement de la taille de la base dedonnées.





Paramètres de simulations [179/223]

Paramètre Description/Signification Valeur

NbOfOperationsNombre d’opérations dans une

[1, 5]transaction utilisateur

OpExecTime Temps d’exécution d’une opération 1sPeriodi Périodicité d’une transaction de mise à jour [1000ms, 5000ms]DBsize Taille de la base de données 300

Paramètres de simulation

Les simulations ont consisté à évaluer le comportement del’architecture en faisant varier les paramètres suivants :

1 Le seuil pour le nombre de version de données.2 Le seuil pour la taille de la base de données.3 Le nombre de transactions "utilisateur" et de mise à jour.





Première expérimentation : Approche no 1 [180/223]

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io

Number of update transactions

One data versionTwo versions Four versionsNumber of versions dynamically adjusted

(a) Pour les transactions de mise à jour

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

ioNumber of user transactions

One data versionTwo versions Four versionsNumber of versions dynamically adjusted

(b) Pour les transactions "utilisateur"

Simulation de l’architecture MVD-FCSA.





Seconde expérimentation en faisant varier le seuil sur la taille de la BDet en utilisant une approche mixte [181/223]

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io


Threshold of Database = 500Threshold of Database = 750Threshold of Database = 1000

(c) Pour les transactions de mise à jour

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io

Number of user transactions


(d) Pour les transactions "utilisateur"

Simulation de MVD-FCSA en utilisant l’approche mixte (nombremaximum de version = 4) et en faisant varier le seuil de la taille de la

BD.





Troisième expérimentation en faisant varier le seuil sur la taille de la BDet en utilisant une approche mixte [182/223]

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io


Thresold of database = 500Thresold of database = 750Thresold of database = 1000

(e) Pour les transactions de mise à jour

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io



(f) Pour les transactions "utilisateurs"

Simulation de MVD-FCSA en utilisant l’approche mixte (nombremaximum de version = 6) et en faisant varier le seuil de la taille de la

BD.





Quatrième expérimentation en faisant varier le nombre de versions dedonnées [183/223]

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io


Four versionsSix versions

(g) Pour les transactions de mise à jour

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io



(h) Pour les transactions "utilisateurs"

Simulation de MVD-FCSA en utilisant l’approche mixte en faisantvarier le nombre de versions de données et avec le seuil de la taille de

la BD = 500.





Cinquième expérimentation en faisant varier le nombre de versions dedonnées [184/223]

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io



(i) Pour les transactions de mise à jour

0

20

40

60

80

100

20 40 60 80 100

Suc

cess

rat

io



(j) Pour les transactions "utilisateurs"

Simulation de MVD-FCSA en utilisant l’approche mixte en faisantvarier le nombre de versions de données et avec le seuil de la taille de

la BD = 1000.





Apports de l’architecture MVD-FCSA [185/223]

L’architecture MVD-FCSA permet :1 de diminuer le taux de manquement des échéances,2 de garantir que les données fraîches sont accédées à temps par

des transactions même en présence de comportementsinprévisibles,

3 de garantir que les données utilisées par des transactions restentfraîches et valides jusqu’au moment de la validation.

4 de garantir la qualité des données (précision et fraîcheur) et destransactions. La qaulité des transactions est augmentée car ondiminue le risque pour les transactions de rater leur échéance.

⇒ la qualité de service globale est améliorée.


Limites de l’architecture FCSADDM-FCSA

La gestion des donnéesdérivées dans les

architectures FCSA



Limites de l’architecture FCSA [187/223]

Prise en compte des données sensorielles uniquement : donnéesissues des capteurs.

⇒ Pas de prise en compte des données temps réel dérivées.Les données dérivées sont des données qui sont calculées àpartir d’une ou plusieurs données sensorielles (dites données debase).Problèmatique : chaque mise à jour d’une donnée de basenécessite la mise à jour de toutes les données dérivées qui endépendent.



Politiques existantes de mise à jour des données dérivéesUn modèle gérant les données temps réel dérivées

Politiques existantes de mise à jour des données dérivées [188/223]

mise à jour déclenchée : chaque MàJ d’une donnée de basedéclenche la MàJ de toutes les données dérivées concernées,

mise à jour à la demande : la mise à jour d’une donnée dérivéen’est effectuée que lorsqu’une transaction en fait la demande,

mise à jour périodique : on déclenche de façon périodique lamise à jour des données dérivées,

mise à jour à délai forcé : la première mise à jour est effectuéesuivant le principe de mise à jour déclenchée, puis on bloque lesmises à jour suivantes durant un délai fixe même en cas de miseà jour des données de base,

mise à jour à retard forcé : on regarde si la transaction qui accèdeà une donnée temps réel peut être “commitée” avant la fin de lavalidité de celle-ci sinon on attend la mise à jour de la donnée.




Mise à jour déclenchée des données dérivées [189/223]

Principe : Chaque fois qu’une donnée de base, intervenant dansle calcul d’une ou plusieurs données dérivées, est modifiée alorson déclenche les transactions de mise à jour correspondantes.

Avantage : Les données dérivées sont recalculées enpermanence et restent toujours fraîches.Inconvénient :

Premier cas : une donnée de base est utilisée dans le calcul denombreuses données dérivées.Deuxième cas : une donnée dérivée est calculée à partir denombreuses données de base.

⇒ De nombreuses transactions de mise à jour sont exécutées.




Mise à jour à la demande des données dérivées [190/223]

Principe : Chaque fois qu’une donnée dérivée est accédée etqu’elle n’est pas fraîche une transaction de mise à jour de ladonnée est exécutée.

Avantage : Le nombre de transactions exécutées est réduit auminimum par rapport aux besoins.

Inconvénient : Lorsqu’une donnée dérivée est accédée etqu’elle n’est pas fraîche, il faut que la transaction qui l’accèdeattende la mise à jour. On augmente ainsi la durée d’exécution dela transaction demandeuse et le risque de manquementd’echéance de celle-ci.




Mise à jour périodique des données dérivées [191/223]

Principe : On déclenche périodiquement les transactions demise à jour des données dérivées.

Avantage : Le déclenchement des transactions se fait seul et estautomatisé.

Inconvénient : Il est difficile de choisir la périodicité de mise àjour car une donnée dérivée dépend potentiellement de plusieursdonnées temps réel qui ne seront pas toutes mises à jour enmême temps. De plus, il peut arriver que la donnée dérivée soitdevenue obsolète et il faut alors attendre la prochaine période demise à jour.




Mise à jour à délai forcé des données dérivées [192/223]

Principe : La première mise à jour est effectuée suivant leprincipe de mise à jour déclenchée, puis on bloque les mises àjour suivantes durant un délai fixe même en cas de mise à jourdes données de base.

Avantage : On dimimue le nombre de transactions de mise à jourqui sont exécutées par rapport à la politique de mise à jourdéclenchée.

Inconvénient : La période d’attente jusqu’à la prochaine mise àjour est inconnue. Des transactions demandant des donnéesobsolètes peuvent être bloquées pendant une période indéfinie.




Mise à jour à retard forcé des données dérivées [193/223]

Principe : On regarde si la transaction qui accède à une donnéedérivée temps réel peut être “commitée” avant la fin de la validitéde la donnée sinon on attend la prochaine mise à jour de ladonnée pour accéder à la donnée.

Avantage : On évite que des transactions accèdent à desdonnées qui seront devenue obsolètes qu moment de leurvalidation.

Inconvénient : Cette politique est difficile à mettre en œuvre(implémenter) La période d’attente bloque toutes les transactionsqui souhaiteraient accéder à cette donnée.




Objectifs de notre modèle [194/223]

Intégrer une politique de mise à jour des données temps réeldans une architecture de contrôle d’ordonancement parrétroaction.

Définir une politique mixte de mise à jour des données tempsréel.

Une architecture capable de prendre en considération lesvariations de charge du système : diminuer ou augmenter lenombre de transactions de mise à jour des données dérivées.




Notre proposition [195/223]

Modification de l’architecture FCSA de base.

Insertion d’un contrôleur d’admission pour les transactions demises à jour des données dérivées.

Utilisation d’un paramètre MVI (Maximum Validity Interval) : ilpermet de contrôler le retard de mise à jour des donnéesdérivées. MVI = 0 ≡ mise à jour déclenchée.

Modification du gestionnaire de fraîcheur.




Politique mixte de mise à jour des données dérivées [196/223]

La mise à jour déclenchée : elle est utilisée durant les périodesde sous-utilisation du système (politique par défaut).

La mise à jour à retard forcé : elle est utilisée quand la charge dusystème augmente. Son principal paramètre de fonctionnementest MVI (Maximum Validity Interval) qui permet de réduire lenombre de MàJ.

La mise à jour à la demande : durant les périodes de surcharge, ilpeut arriver que les données dérivées de part leur faiblefréquence de mise à jour deviennent obsolètes. Lorsqu’unetransaction demande l’accès à une donnée dérivée obsolète, legestionnaire de fraîcheur va effectuer une demande mise à jour.




Une nouvelle architecture [197/223]

Moniteur

UUnouveau

....Source1

Sourcem

Contrôleur

de précision

Gestionnaire

de QdD

....Flux

Fluxm

1

des données de baseTransactions de MàJ

....Flux

Fluxm

1

des données dérivéesTransactions de MàJ

Contrôleur

d’admission

MDE

PourcentageMDETransactions Utilisateur d’échéances ratées

Envoi



Fraîcheur

Bloquée

Abandon

Redémarrage/Suspension

Déclencheur de transactions

Contrôleur d’utilisation et d’échéances ratées

FM CC BSFile des transactionsprêtes

Contrôleur d’admission

des données dérivéesdes transactions de màj

Ordre de mise à jour à la demande

MVI

Architecture de contrôle d’ordonnancement par rétroaction pour lagestion des données dérivées temps réel




Fonctionnement de la nouvelle architecture [198/223]

Lors des périodes de surcharge, la répartition de l’effort s’effectueentre :

les transactions "utilisateur",

les transactions de mise à jour des données de base(sensorielles),

les transactions de mise à jour des données dérivées.

⇒ Intégration d’un nouveau paramètre de qualité de service : MVI.




Le paramètre MVI et la qualité des données dérivées [199/223]Le paramètre MVI (Intervalle de validité maximale) permet de fairevarier le nombre de transactions de mise à jour des donnéesdérivées :

si MVI augmente alors on bloque la mise à jour des donnéesdérivées pendant plus longtemps ⇒ diminution du nombre detransactions de mise à jour des données dérivées.

si MVI diminue alors on bloque moins longtemps la mise à jourdes données dérivées ⇒ augmentation du nombre detransactions de mise à jour des données dérivées.

si MVI=0 alors toutes les transactions déclenchées sontacceptées.

La qualité des données dérivées :

Si MVI augmente, la qualité des données dérivées diminue.

Si MVI diminue, la qualité des données dérivées augmente.




Contrôleur d’admission des transactions de mise à jour des donnéesdérivées [200/223]

À chaque mise à jour d’une donnée de base, toutes les donnéesdérivées qui utilisent cette donnée doivent être mises à jour.⇒ déclenchement d’une transaction de mise à jour pour chaquedonnée dérivée concernée.Comportement du contrôleur d’admission :

Par défaut (MVI=0), il accepte toutes les transactions qui entrentdans le système.

Si MVI>0, il attend un temps minimal entre les différentes mises àjour. Ce délai d’attente est fixé par MVI.

Il répond aux ordres de mise à jour donnés par le gestionnaire defraîcheur lorsque celui-ci en fait la demande, même si le délaid’attente MVI n’est pas écoulé complètement.


Quelques éléments générauxDescription du problème et analyse

FCSA-DMMS

Les SGBD temps réel et lessystèmes multimédia



FCSA-DMMS

Introduction et contexte (1/2) [202/223]

Les avancées de l’informatique et des réseaux informatiquespermettent de rendre plus populaires les systèmes multimédia etles applications Internet.

Il est désormais possible pour un grand nombre d’utilisateurs deregarder des vidéos en mode streaming ou de lire en temps réeldes données multimédia sur Internet.

L’acroissement de la demande pour ces applications destreaming vidéo sur Internet va prochainement amener lesréseaux à subir des périodes de saturation.

Le format de vidéos MPEG est devenu l’un des plus populairespour les applications multimédia telles que les visiophones, lessystèmes de visio-conférence, les systèmes interactifs tels que lavidéo à la demande.



FCSA-DMMS

Introduction et contexte (2/2) [203/223]

Certains systèmes de vidéos à la demande existant fonctionnentsur des réseaux avec une bande passante dédiée.

Il serait intéressant d’avoir des systèmes qui fonctionnent sur desréseaux non contrôlés tels que l’Internet.

C’est pourquoi un grand nombre de travaux de recherche ont étéeffectués sur des systèmes distribués pour le streaming vidéo surdes réseaux non contrôlés et ouverts.

Les lecteurs de vidéo MPEG sont des systèmes strictes noncritiques. Chaque séquence vidéo doit être affiché correctementet à temps.



FCSA-DMMS


Comment faire en sorte que les périodes de surchargen’entraînent une défaillance des applications et des pertes deperformance trop importante ?

Comment mettre à profit les périodes pendant lesquels lesapplications informatiques et les réseau ne sont plus sollicités defaçon intense ?

Comment concevoir des systèmes multimédia qui tiennentcompte de la dynamicité des demandes ?

Le nombre de clients n’est pas connu à l’avance.



FCSA-DMMS

Solutions [205/223]

Diminuer la qualité de service offerte lors des période desurcharge ou de forte de demande de la part des utilisateurs.

Mettre à profit les périodes de sous-utilisation.

⇒ L’approche à utiliser est donc une approche basée sur la gestionde la qualité de service.

⇒ Objectif : garantir une certaine qualité de service à à l’ensembledes clients seulement si c’est possible.Technique employée :

utiliser un contrôleur d’admission pour ajuster le nombre de clientsadmis dans le système selon les capacités du réseau et desserveurs vidéo.utiliser les avantages fournis par le calcul imprécis et lesmécanismes d’ordonnancement par rétroaction.



FCSA-DMMS

La compression vidéo au format MPEGLes applications multimédiaLes résultats/solutions imprécisesL’ordonnancement avec rétroaction

Quelques éléments généraux [206/223]

La compression vidéo au format MPEG.

Les applications multimédia.

Les résultats/solutions imprécises.

L’ordonnancement avec rétroaction.

L’architecture QMPEGv2.



FCSA-DMMS


La compression vidéo au format MPEG (1/3) [207/223]

Une vidéo est une simple succession d’image fixe qui sont aussiappelé frame.

Chaque image peut être compressée au format JPEG.

Dans une séquence vidéo, succession d’image, il existe de laredondance notamment s’il y a peu de mouvement.

Le format MPEG tient compte de cette redondance inter-framespour construire ses séquences vidéos.MPEG prends en entrée une séquence de frames et lacompresse en trois type de frames :

Frame I (Intra-Frame),Frame P (Predictive Frame),Frame B (Bidirectionnal Frame).



FCSA-DMMS



Frame I (Intra-Frame) :Indépendante des autres frames.Une image JPEG.Elles sont indispensable pour la décompression.

Frame P (Predictive Frame) :Dépendance vis-à-vis des autres frames.Spécifications des différences avec la frame I précédente.

Frame B (Bidirectionnal Frame) :Dépendance vis-à-vis des autres frames.Spécifications une interpolation entre une frame précédente etune frame suivante de type I et P.



FCSA-DMMS



CompressionMPEG

Frame 1 Frame 2 Frame 3 Frame 4 Frame 5 Frame 6 Frame 7Fluxd’entrée

Fluxcompressé Frame I Frame B Frame B Frame P Frame B Frame B Frame I

Prédiction en arrière

Prédiction bidirectionnelle



FCSA-DMMS


Les applications multimédia [210/223]

Le terme multimédia désigne un ensemble d’applications,produits ou technologies.Deux classes d’applications :

celles de type conférence,celles de type streaming.

Les applications de type streaming délivrent des flux audio etvidéos depuis un serveur vers un client (comme par exempleRealPlayer).

Elles ne peuvent utiliser un support fiable tel que TCP car il nepeu garantir l’arrivée des données dans les temps.

Un autre composant clé des systèmes multimédia distribués estles systèmes de bases de données



FCSA-DMMS


Les résultats/solutions imprécises [211/223]

Dans un système temps réel stricte non critique, les échéancesdoivent être respectées sinon les tâches deviennent inutiles pourle système.

Les techniques de calcul imprécis peuvent aider au respect descontraintes temporelles.

Elles fournissent des résultats à l’utilisateur de qualité dégradéemais acceptable dans les temps.

On peut donc appliquer ces techniques aux systèmes multimédiaafin de dégrader la qualité des séquences vidéos par le biais dela suppression de frames de type P ou B.



FCSA-DMMS


Dégrader la qualité d’une séquence vidéo [212/223]

Suppression de frames de type B ou P.



FCSA-DMMS


L’ordonnancement avec rétroaction [213/223]

On cherche à contrôler les performances du système temps réelen ajustant la configuration de telle façon à ce que lesperformances du systèmes convergent vers une qualité deservice spécifiée.

Un système basé sur l’ordonnancement par rétroaction consisteen un système contrôleur et un système contrôlé.

L’objectif étant de contrôler le système de façon à ce qu’ilconverge vers ses paramètres de référence.

L’ajustement d’un niveau de qualité de service se fait par exempleen modifiant le nombre de frame dans un GoP.

Les performances du système peuvent aussi être contrôlé aumoyen d’un contrôleur d’admission qui limite le nombre de clientsacceptés en fonction de la charge du système.



FCSA-DMMS


L’architecture QMPEGv2 (1/2) [214/223]Il s’agit d’un système vidéo distribué qui est basé sur unearchitecture multi-serveurs.QMPEGv2 est composé de trois parties :

Le serveur maître reçoit les demandes des clients, leur alloue unserveur vidéo et régule les flux de données vidéo de façon à cequ’une certaine QdS soit maintenue.Les serveurs vidéo transmettre aux client les données vidéos etagissent sous le contrôle du serveur maître.Les clients reçoivent les frames vidéos depuis le serveur vidéo etdoivent jouer à temps celles-ci. Pour cela, chaque client disposed’un buffer de réception et lorsqu’un changement se produit ennotifie le serveur.

Exemple de scénario d’utilisation :1 Le client initie la demande d’une vidéo et l’envoi au serveur.2 À la réception de la demande, le serveur maître sélectionne le

serveur vidéo le moins chargé pour répondre à la demande.3 Une connexion est établie entre le client et le serveur vidéo.



FCSA-DMMS


L’architecture QMPEGv2 (2/2) [215/223]

Le serveur maître agit comme un ordonnanceur qui régule le fluxet la qualité de service des données en fonction des conditionsréseaux.Trois facteurs ont été considéré comme important pour laconception de ce système :

une bonne transmission du coté serveur,une gestion efficace du buffer coté client,un mécanisme de contrôle entre le client et le serveur afin de tenircompte des délais du réseau.

La transmission des frames se fait sous le contrôle de la qualitéde service. Ceci signifie que le module de contrôle de la qualitéde service est le seul à pouvoir décider de la suppression deframe.

La mesure de la qualité de la vidéo est basé sur le point de vuehumain. On parle de QoS-human.



FCSA-DMMS

Le calcul imprécisSpécification de la QdS


Il existe une forte demande pour des systèmes de streamingvidéo fournissant une bonne qualité de service.

Les systèmes commerciaux existant nécessitent un réseau avecune bande passante fiable et un buffer de grande taille.

Ils ne fournissent pas de garanties de qualité de qualité deservice.

Lorsqu’il n’existe pas suffisamment de bande passante disponiblela suppression de frames se fait de façon aléatoire et incontrôlée.

Très peu de systèmes permettent aujourd’hui de faire dustreaming vidéo sur Internet.



FCSA-DMMS


Le calcul imprécis appliqué aux flux MPEG [217/223]

Afin de garantir le comportement des serveurs vidéos dans unenvironnement imprévisible, on utilise une approche basée sur laqualité de service.

Il est nécessaire d’avoir des serveurs qui sont flexibles, quipeuvent s’adapter aux conditions existantes du réseau et quipeuvent effectuer une dégradation de la qualité de service d’unemanière contrôlée.

Il est possible d’appliquer la notion d’imprécision sur des GoP.



FCSA-DMMS


Spécification de la qualité de service [218/223]

QoS level : c’est le nombre de frames transmis dans chaqueGoP.ClientQoS : c’est la moyenne du niveau de QoS coté client.ServerQoS : c’est la moyenne du niveau de QoS coté serveur.minQoS : c’est la qualité de service minimum admise cotéserveur.maxQoS : c’est la qualité de service maximum admise cotéserveur.Une augmentation de ServerQoS et et suffisamment de bandepassante entre le serveur vidéo et le client conduisent à uneaugmentation de ClientQoS.Deux cas peuvent conduire à la diminution de ClientQoS :

Une augmentation de ServerQoS et une congestion du réseau.Une dégradation de ServerQoS afin d’éviter une congestion duréseau.



FCSA-DMMS

FCSA appliquée à un système multimédia distribué [219/223]



FCSA-DMMS

Fonctionnement de l’architecture [220/223]1 Un client envoi une demande pour obtenir une vidéo avec un

certain niveau de qualité de service au serveur maître.2 Le serveur maître diffuse la requête auprès de l’ensemble des

serveurs vidéo qu’il connait.3 Le serveur vidéo qui est en mesure de fournir la qualité de

service requise répond au serveur maître.4 Un flux est ouvert entre le serveur vidéo qui a répondu

favorablement et le client concerné.5 Le client envoie un rapport (de rétroaction) au serveur maître

pour lui rendre compte de la qualité de service réellementobtenue par rapport à celle demandée.

6 Le serveur maître adapte alors la qualité de service fournie afinde se rapprocher de la qualité de service demandée.

7 Modification du flux et de la qualité de service puis onrecommence à l’étape 5.



FCSA-DMMS

Bilan sur l’application de FCSA aux systèmes multimédia [221/223]

Il est possible dans l’avenir de concevoir des systèmes pour lestreaming vidéo basé en garantissant une certaine qualité deservice.Pour cela, il faut :

spécifier les paramètres de qualité de service,construire des algorithmes d’équilibrage de charge basééventuellement sur le retour d’expérience,utiliser des méthodes de calcul imprécis pour faire varier la qualitédes résultats obtenus.

Dans les systèmes vidéo, on peut faire varier la qualité de serviceà la fois du coté client mais aussi du coté serveur.

Ces techniques peuvent se baser sur l’utilisation de SGBDTR quioffriraient des outils pour la gestion de la qualité de service.

Certaines de ces techniques peuvent être utiliséesindépendamment des autres.



FCSA-DMMS

Problèmes/Inconvénients de ces méthodes [222/223]

Il n’existe pas encore de tels outils commerciaux et seul quelquesprototypes universitaires existent (Exemple : Beehive).

Il faut donc éventuellement tout programmer soi-même ou alorsprogrammer des extensions des SGBD actuels pour prendre encompte ces concepts.

Dans l’avenir certains prototypes universitaires deviendront sansdoute des outils commerciaux (à la manière d’O2).

Certains SGBD commerciaux intégrerons les aspects temps réelet la gestion de qualité de service.



FCSA-DMMS

Dernier transparent [223/223]

Mise en ligne des transparents sur la page :http ://litis.univ-lehavre.fr/∼duvallet/enseignements-GABES-fr.php

Rappel de mon adresse (courriel) :[email protected]


les systèmes de gestion de bases de données...

Documents