ContrôLe De La Concurence Sgbd Temps RéEl SystèMe Dexploiration

SystSystèèmes dmes d’’exploitation m.aexploitation m.a/ INFO 2306/ INFO 2306

«« Le Le contrôlecontrôle de la concurrence de la concurrence dansdans les SGBD temps les SGBD temps rrééelel»»

Namur, juin 2007Pierre HALLEUX, [email protected]

Professeur : Jean RAMAEKERSAssistant : Hubert TOUSSAINT

Pierre HALLEUX

Présentation d’après l’article :«Analyse des protocoles de contrôle de concurrence et des propriétés ACID

dans les SGBD temps réel , C. DUVALLET*, Z. MAMMERI**, B. SADEG*LIH, Facultés des Sciences et Techniques*, IRIT Université Paul Sabatier Toulouse**»

Systèmes d’exploitation (m.a) « Gestion de la concurrence dans les SGBD temps réel s », Pierre Halleux, [email protected]

• 1. Introduction

• 2. Application temps réel

• 3. Données et transactions dans les SGBDTR

– Les données

– Les transactions

• 4. Protocoles de contrôle de concurrence et ordonna ncement de transactions temps réel

– Problématique

– Techniques optimistes :OCC-BC, Wait 50, CCA

– Techniques pessimistes: Abandon par priorité, héritage de priorité

– Synthèse

• 5. Remarques concernant propriétés ACID dans les tr ansactions temps réel

• 6. Conclusion

Plan de la prPlan de la pr éésentationsentation


1. Introduction & probl1. Introduction & probl éématique (1/3)matique (1/3)

• Depuis +- 10 ans : nouvelles applications, défi� contraintes temporelles� données de nature différentes

• Caricature d’un SGBTR :� SGBD traditionnel + système temps réel.

2 objectifs : - Traiter transactions ACID- Fonctionner en TR

• Application TR :- Système contrôleur (le SI)- Système contrôlé (l’environnement) : acquis par capteurs distribués

• But : effectuer des calculs, manipuler des données (ex : industrie…)• Besoin : Cohérence logique & contrainte temporelle

� besoin d’ordonnancement


1. Introduction (2/3)1. Introduction (2/3)

• Domaine d’application :– Aéronautique (moteur d'avion), médical (un patient) , économique (système boursier), . . .

• Exemple : « un système de contrôle de trafic aérien »

– Taille et le volume du trafic de l'espace aérien contrôlé � � complexité

– Système distribué : serveurs connectés via un réseau � Contrôler le trafic

– Systèmes externes : stations météorologiques, radars : fournir 100 à 200 rapports/scrutation.

► Les serveurs - exploitent les données des radars (déduirent les trajectoires des avions)

- enregistrent les données sur des supports pour des analyses ultérieures.

► Les stations de travail - affichent des informations TR (trajectoires, alertes, météorologie,. . .).

� L'application - manipule des quantités importantes d'informations

- fournit des résultats dans les temps.


1. Introduction (3/3)1. Introduction (3/3)

• Contraintes temporelles et durée de validité

– (! Résultats à temps) � dérèglement de trafic � collisions,…

• Besoin ? – Garantir la cohérence des données : gestionnaire de transactions pour éviter les conflits*

*Read/Write ou Write/Write


2. Application temps r2. Application temps r ééel (1/2)el (1/2)

• Application TR :– Gérée par un système contrôleur (Système informatique)

– Agit sur son environnement (Système contrôlé)

• Fonctionnement :– Acquisition de données du système contrôlé à l'aide de capteurs

– Traitement des données avant la fin du délai

– Envoi d'ordre de commande sur l'environnement à l'aide d'actionneurs.

• Etendue :– du microcontrôleur qui permet le contrôle du système de freinage d'une voiture,

… au système réparti qui permet le contrôle du trafic aérien

• Défiinition :

– « A real-time system is defined as a system whose correctness of the system depends notonly on the logical results of computations, but also on the time at which the results are produced ».


2. Application temps r2. Application temps r ééel (2/2)el (2/2)


3. Données et transactions dans SGBDTR (1/10)

A) Les données• Un objet temporel : état peut devenir inexploitable au fil du temps.

Associé à un état et à un intervalle de validité temporel.

• Objet non-temporel : état reste valide au fil du temps.

• Les objets de base : objet qui reflètent des entités concrètes de l'environnement.

mis à jour périodiquement par les transactions qui lisent les capteurs.

Ex. : température, pression, . . .

• Les objets dérivés :

Des nouveaux objets dérivés à partir d'objets de base via les transactions.

Ex. : les données acquises sur la position et la vitesse d'objets en mouvement sont utilisées pour

dériver la nouvelle commande à appliquer au robot qui permet de déplacer ces objets.

• Déclenchement des transactions : ECA.

Ex. : Objets de base : point de départ, la vitesse et la trajectoire d'un avion. Objet dérivé : la position)



B) Les transactions

• Type de transactions : selon l’importance accordées aux échéances et niveau d’interactions avec l’environnement

Contrer un missileGravesStricte

& critique

Hard

Système multimédiaQuasi nullesNon-stricteSoft

Robot tapis

& roulant…

Négligeables

(on abort…)

Stricte

& non critique

Firm

ExempleConséquences

sur environnement

EchéanceTransactions



B) Les transactions (suite…)

• Modélisation à l’aide d’une fonction valeur



• Une transaction : – ensemble d’actions (lecture, écriture, calcul)

– agir sur une base de données

– en gardant son état cohérent.

– se termine par « comit » ou « abort »

– Constituée de sous-transactions (ou pas)

• Dans les SGBDTR :– deadline : hard,soft ou firm

• Plusieurs états liés :– aux conflits d'accès aux données

– à la priorité de l'échéance.

� Distinction des états :

� active (en cours d'exécution),

� wait (état bloqué),

� commit,

� rollback (annulation).







Echéances des transactions dans les SGBD temps réel

• les transactions possèdent des contraintes de temps (souvent sous forme d'échéances)

(Proviennent de deux sources) – Contraintes temporelles liées à

• L'environnement(Ex: l'action qui corrige la trajectoire d'un robot téléguidé doit s'exécuter avant que le robot ne rentre en collision avec un obstacle),

• Des choix de conception et d'implantation d'une application

(Ex; durée d'exécution d'une opération sur un processeur choisi ou délai de communication de messages).




• Exemple : échéances des transactions– T : transaction de lecture qui doit produire un résultat

– Y et Z : données TR

– Lecture de Y à l’instant tb, de Z en tc dans l’environnement

– T a besoin de lire les deux données temps réel Y et Z pour produire un résultat. L

– Échéance de T : l'instant tf (initialement égale à 13),

– Durée de validité absolue : Y = 7 unités de temps, Z = 3 unités de temps.

Hyp:

– T commence en ta =1

– En tb = 4 T lit Y, son échéance devient 11 (Tb+7) (après 11 Y invalide…)

– En tc = 6 T lit Z, son échéance devient Tf =Tc +3 = 9 (après 9 Z invalide…)

– � Si T ne finit pas avant t=9, alors elle est abandonnée

Nb: elle pourrait redémarrée, lire Y et Z en t=11 et t=12 et finir avant l’échéance finale tb=13




• Simulateur d’arrivée de transactionsB) Les transactions (suite…)





• Double objectif d'un SGBDTR :– Garantir l'exécution et la validation (avant leurs échéances) des transactions à échéances

strictes et critiques– Minimiser le nombre de transactions

• à échéances strictes et non-critiques

• ou à échéances non-strictes

qui ratent leurs échéances.

• Essais à l’aide de SGBD classique?

� Traiter encadrement des quantité importantes de données ☺� Objectif en terme de performances = t réponse moyen des transactions �

• Délais variés en fonction du DA :– La milliseconde pour les systèmes de radar,– La seconde pour les systèmes de visualisation humaine,– Quelques heures pour le contrôle de production impliquant des réactions chimiques,– 24 heures pour les prévisions météo,– Plusieurs mois ou années pour les systèmes de navigation de sonde spatiale,


• Problématique:– Accéder simultanément aux données stockées dans bd par plusieurs transactions.

• Exécution concurrentes

• (1) SGBD Traditionnels :– Cohérence & accès concurrents : ordonnancement sérialisable

• Deux transactions sont sérialisable si le résultat de leur exécution concurrente

est le même que celui de leur exécution séquentielle.

• (2) SGBD TR :– tous les ordonnancements sérialisables ne sont pas acceptables!

• ceux qui ne respectent pas les contraintes temporelles des transactions sont rejetés.

Les techniques (1) ne sont donc pas directement applicables en (2)

Car il faut en (2) maintenir cohérence logique & temporelle !

� Les techniques de (2) sont pessimistes ou optimistes

4. Protocoles d’ordonnancement & contrôle de concurrence (1/15)


Méthodes 1 : Techniques « pessimistes »:

Hypothèse fondamentale :

Toute paire de transactions qui s'exécute en concurrence est susceptible de rentrer en conflit.

• Utilise des verrous pour empêcher les conflits potentiels : – l'opération de lecture/ écriture est validée avant l'accès à la donnée.

– empêchent les conflits avant même qu'ils ne surviennent.

• Verrous sur les données avant tout accès.

• T accède à une donnée � elle a obtenu un verrou sur cette donnée. càd � pas encore verrouillée par T’ avec un mode incompatible

Si verrou refusé : T doit attendre que la donnée se libère

(+) conflits sont détectés dès leur apparition: Garanti la validité de tous les accès aux données.

(-) Protocole "bloquant" : T mise en attente jusqu’à validation de T’



Méthodes 1 : Techniques « pessimistes »:

Hypothèse fondamentale :

Toute paire de transactions qui s'exécute en concurrence est susceptible de rentrer en conflit.




Méthodes 2 : Techniques « optimistes »:

Hypothèse fondamentale : Laisse les transactions s'exécuter en concurrence

• Vérifie la présence de conflits– uniquement quand la phase de validation atteinte

– Les transactions en conflits sont alors abandonnées puis redémarrées selon certaines hypothèses.

� Vérifier apparition de conflit avant commit (méthode de certification)

- Certification « en arrière »

- Certification « en avant »



• Certification "en arrière". – Par rapport aux transactions validées.

– Objets lus par Tc en phase de validation sont examinés.

• Si l'un d'eux est écrit par une transaction

qui a exécuté sa validation après le début de l'exécution de Tc,

• Alors la transaction Tc est abandonnée,

(car elle pourrait ne pas avoir pris connaissance de la nouvelle valeur de l'objet)

• Certification "en avant". – Par rapport aux transactions actives.

– Objets écrits Tc sont comparés à tous les objets lus par toute transaction active.

• S'il y a des objets communs entre Tc et ces transactions,

• Alors une erreur de sérialisation est détectée.

• Possibilité d'abandonner soit

la transaction Tc,

les transactions avec lesquelles elle est en conflit


4. Protocoles d’ordonnancement & contôle de concurence

Techniques optimistes : > OCC-BC - Optimistic Concurrency Control - Broadcast Commit

• Minimiser les pertes de ressources en redémarrant les transactions le plus tôt possible.

• Certification en avant + priorités des transactions.

– La transaction qui effectue une validation avertisse de sa validation toutes les transactions qui sont en conflit avec elle.

� � chances de se terminer avant leurs échéances en les redémarrant immédiatement.

• Tc en phase de validation. – Si, avant sa validation,

• cette transaction entre en conflit avec d'autres transactions T1, T2,..., Tn :

(+) Tc se met en attente et garde donc les ressources qu'elle avait acquise. � Améliore les performances du système, pas à redemander ces ressources.





• Exemple T1 et T2 sont en conflit : T2 lit une donnée x, après que T1 l'ait mise à jour. – OCC :

• T2 doit être redémarrée dès qu'elle rentre dans sa phase de certification

(car elle est en conflit sur la donnée x avec une transaction qui a déjà effectué sa validation).

Pr [T2 s'exécute avant sa deadline après son redémarrage] ⇓ ⇓.





• Exemple T1 et T2 sont en conflit : T2 lit une donnée x, après que T1 l'ait mise à jour. – OCC-BC:

– on évite d'attendre jusqu'à la certification de T2 pour la redémarrer.

– Conséquence à la notification de toutes les transactions en conflit avec T1 lors de sa validation.

– T2 est redémarrée immédiatement après la validation de T1.




Techniques optimistes : > Wait(50)

• Evite les inconvénients de OCC-BC = "stratégie de compromis".

• Un mécanisme de "contrôle de l'attente " (nouveau) + attente par priorité

Tc = T courante Ti = T actives en conflit avec la transaction courante.

X = représente le pourcentage de résolution de conflits (avec les transactions actives)que la transaction courante doit attendre avec son commit.




Techniques optimistes : > CCA - Cost Conscious Approach

• Basé sur– Earliest Deadline First-High Priority (EDF-HP)

• priorité plus grande à la transaction dont l'échéance est imminente.

– Earliest Deadline First-Conditional Restat (EDF-CR) • ajoute une estimation du temps d'exécution des transactions.� permet à des transactions non-prioritaires de se terminer,

à condition qu'elles n'obligent pas les autres transactions en conflit ayant une échéance à plus haute priorité à rater leurs deadlines.

Basée sur une approche dynamique.

• Pré-analyse des transactions (similaire à l'algorithme A* en IA – arbre décision) pour connaître – la structure des transactions– les données potentiellement accédées (en fonction des chemins d'exécution).

• Prend donc en compte des – Aspects statiques : échéances,. . .– Aspects dynamiques (temps effectif d'exécution, coût des redémarrages,. . .)

� Possible de réduire la zone de conflits.




Techniques optimistes : > CCA - Cost Conscious Approach

• Exemple : A et B concurrentes.


Certains cas d'exécution n'entraînent pas de conflits. ∃ conflit sur les données X,Y et ZMais les feuilles Ae et Af ne posent plus de conflits.

(+)Aspect dynamique : Déterminer progressivement si des conflits sont susceptibles de survenir en cours d'exécution et donc de diminuer les blocages.(-) Coût de la préAnalyse…



Techniques pessimistes (Blocantes) :

• Rappel : Utilisent la notion de verrou pour empêcher l'accès incompatible aux données par les T

• Algo en 2 étapes :– Acquisition des verrous et exécution des actions de T

– Libération des objets verrouillés.

Si Td demande un verrou sur un objet détenu par Ta & mode conflictuel

Alors , Td est bloquée jusqu'à la libération du verrou sur l'objet par Ta.

• 2 Familles d’algo.– Abandon par priorité

– Héritage de priorité.




Techniques pessimistes (Blocantes) : > Abandon par priorité

• Idée : abandonner T (de plus basse priorité) quand le phénomène d'inversion de priorité survient.

– Inversion de priorité : si T doit attendre qu’une transaction de plus faible priorité T’ libère une ressource dont T a besoin.

• (+) Transaction haute priorité ne soit pas retardée par basses priorités. – Garantir pour transactions urgentes

• (-) Transactions de basse priorité pourraient toujours rater…– � Perte de travail & dégradation des performances du système.




Techniques pessimistes (Blocantes) : > Héritage de priorité

• Idée : assigner une nouvelle priorité à toute transaction accédant à un objet partagé, – Permet de s'exécuter à un niveau de priorité plus élevé que celui des transactions qu'elle bloque.

Si « inversion de priorité survient »

Alors , la transaction de plus faible priorité voit sa priorité augmentée

et ramenée au niveau de celle de la transaction demandeuse du verrou, – jusqu'à ce qu'elle se termine et libère le verrou.

• (+) T qui possèdent des verrous – se termineront plus tôt

– réduire ainsi les temps d'attente des transactions de haute priorité.

• (-)– Temps de blocage des transactions de haute priorité reste imprévisible,

– Blocages en chaîne : T de haute priorité se bloque plusieurs fois en attente des T de plus basses priorités,

– T de faible priorité de concurrencer les T à haute priorité pcq elles ont hérité…



Techniques pestimistes (Blocantes) : > Héritage de priorité

Durée de blocage imprévisible, blocages en chaîne

Adapté au temps réel stricte non critique

Héritage de prioritéP

Certaines transactions abandonnées au profit de transactions qui ne terminent pas à Temps…perte de temps pour le système

Les transactions à plus haute prioritéterminent plus facilement à temps, nombre d'abort réduit

Abandon de prioritéP

Ne tient pas compte du coût de la pré-analyse des transactions (construction d'arbres de décision)

Nombre d'abort réduit, tient compte du coût des abort et intègre les contraintes à échéances non-strictes

CCAO

Cfr OCC-BC mais de façon plus modéréeRessources bloquées moins longtemps que pour OCC-BC. Nombre d'abort réduit

Wait-50O

Abort très nombreux, Lock sur ressources liées àla transaction en attente, risque de conflits, baisse des performances du système

T en phase de validation est privilégiée et garde les ressources acquises

OCC-BCO

InconvénientAvantageProtocoleTech.




SGBD traditionnel :

• Atomicité : principe du "tout ou rien", (toutes les actions de la transaction sont exécutées, soit aucune ne l'est.

• Cohérence : BD cohérente avant & transaction � BD cohérente après.

• Isolation : les modifications effectuées par une T visibles et exploitables par les autres T seulement après sa phase de validation (Commit).

• Durabilité : la propriété de durabilité indique qu'une fois la transaction validée (Commit), � modifications permanentes

5. Propriétés ACID en TR



SGBD TR :

• Atomicité partielle :

– on accepte qu’une partie de la transaction ne soit pas exécutée

– préférable d'obtenir un résultat imprécis dans les temps qu'un résultat complet en retard .

– Intéressant d’avoir une pré-analyse pour trouver sous ensemble d’actions:

• qui doivent impérativement respecter leur échéance,

• que l'on peut abandonner si elles ratent leurs échéances

• dont l'exécution peut se poursuivre même si la transaction globale a raté son échéance.

• Cohérence partielle : – certaines méthodes autorisent un certain niveau d'erreur sur les données.

• Isolation partielle : – heuristiques relaxent la propriété d'Isolation en autorisant les T à manipuler des données non-encore validées.

• Durabilité partielle : – durée de validité très courtes � stockage en mémoire principale

• Peu de garantie en cas de crash du SGBD

5. Propriétés ACID en TR (1/2)



• Conclusion : – Mise en évidence de la problématique relative aux applications temps réel

– Garanties non suffisantes dans SGBD classiques � SGBD temporel

– Similitudes SGBD traditionnels & SGBD TR : problèmes de concurrences de transactions.

• Définit : transactions TR, données TR.

• Enoncé quelques algorithmes de gestion de la concurrence.

– Autres problèmes restent ouverts et méritent d'être étudiés :

• Le stockage des données temps réel : mémoire principale ou mémoire secondaire,...

• Les protocoles de contrôle de concurrence à plus faible coût,

• La gestion des buffer et l'ordonnancement des opérations d'entrées/sortie,

• …

6. Conclusion (2/2)

Merci de votre attention

Des questions?

Pierre Halleux, [email protected]

Business

ContrôLe De La Concurence Sgbd Temps RéEl SystèMe Dexploiration