Vous êtes sur la page 1sur 53

Cours Algorithmique parallèle

Enseignant: Sofien Chtourou


Institut Supérieur d’Informatique et du Multimédia

CHAPITRE I: THREAD ET PROGRAMMATION PARALLÈL


Applications réparties
 Coopération entre machines qui communiquent à
travers un réseau.
M5
M4

M1 Réseau de
communication

M2 M3

 Partage des données, des ressources et des


traitements.
Applications réparties
 Services de distribution des traitements sur
plateformes hétérogènes.
 Cohérence du système.
 Synchronisation.
 Ordonnancement.

 Masquer aux applications distribuées l’hétérogénité


des plateformes d’exécution.
 outils de développement
 services
Applications réparties
 Faire communiquer des programmes entre eux.
 Sur deux machines différentes à travers un réseau.
 Sur une seule machine.
 La communication : échange sécurisé de données.
 La synchronisation des programmes.
 Ressource partagée : gestion des conflits d’accès …

Nécessité de programmes qui assure la communication


entre les différents tiers de l’application répartie.
Applications réparties

Un intergiciel (middleware) : programme


qui s’insère entre deux applications assurant
la communication des machines entre elles.

 La communication est assurée indépendamment:


 De la nature du processeur.
 Du système d’exploitation.
 Du langage de programmation.
Applications réparties
 Concurrence :
 Plusieurs tâches accèdent simultanément à une même ressource.

 Gestion de l’accès à cette ressource commune par partage de


temps.
 Parallélisme :
 Exécution simultanée de plusieurs tâches sur la même machine.
 Synchronisation et passage de messages.
 Distribution :
 Plusieurs tâches d’une même application sont exécutées sur des
machines différentes reliées par un réseau.
Applications réparties

 On dit talon, souche ou amorce


 Comment on peut obtenir les talons?
Applications réparties
 Talon coté client:
 reçoit l’appel en mode local.
 Emballe les paramètres et le transforme en appel
distant en envoyant un message.


Applications réparties
 Talon coté serveur:
 Reçoit l’appel sous forme de message.
 Déballe les paramètres d'appel.


Applications réparties
Des programmes
générées servant
à
l’implémentation
d’une application
répartie

Types définis dans X Squelettes pour


implémenter les
services
Applications réparties
11

 Des applications sures : tolérances aux pannes.


 Un problème réseau rend l’application inutilisable.
 Panne coté serveur : attente indéfinie par le client d’une
réponse qui ne viendra peut être jamais.
 Utilisation d’une horloge de garde.
 Risque de confusion après relance du client entre les nouvelles
réponses attendues et les réponses de l’ancienne requête.
 Distinction entre requête utiles et orphelines (à détruire).
 Applications sécurisées :
 Échange de données cryptées.
 Accès restreint aux services.
Applications réparties
12
 La scalabilité:
 Applications supportant la montée en charge.
 Processus serveur unique

 Processus par service

 Aspects avancés : Topologie dynamique de l’application.


 La mobilité.
 La reconfiguration dynamique.
Évolution technologique
 Application classique.
 Application client serveur:
 Transmission de données (html, XML) entre client et
serveur.
 Socket, JSP (Java Server Pages), Servlet, CGI
(Common Gateway Interface).
 Invocation de méthode à distance
 Protocole d’appel de méthodes à distanceRPC (Remote
Procedure Call)
Évolution technologique
 Évolution de la technologie vers l’objet distribué
 Solution SUN: distribution en JAVA.
 RMI: Remote Method Invocation.
 CORBA : Common Object Request Broker Architecture .
 Plusieurs langages (java, C++) et différents systèmes d’exploitation (Unix, Windows et
…).
 Solution Microsoft:
 DCOM : Distributed Component Object Model.
 un seul langage de programmation (C++) et un seul système d’exploitation (Windows).
 Évolution de la technologie vers les composants
 Les EJB: Entreprise Java Beans.
 Les composants sont gérés à travers un serveur d’application:
 Solution libre : JBOSS, Solution IBM : Websphere
Évolution technologique
 Modèle client serveur
requête

client serveur
réponse

 Invocation de méthodes à distance


Client Serveur API : ensemble complet et
API+talon intégré de services pour le
API+talon
développement, l’utilisation
Réseau+OS Réseau+OS et l’administration
d’applications distribuées.
Évolution technologique
 Client :  Métier
 Riche (lourd) : application java  Composants EJB
 Léger : navigateur web  SGBD
 Présentation  Oracle, SQLServer,
 Composants web : servlet, jsp, ..  PostGreSQL
Évolution technologique
 Focalise sur la
logique applicative:
 Services systèmes
fournis par le
conteneur
 Les composants sont
portables d’un serveur
à un autre.
L’architecture d’environnement de
développement d’application distribuée

Appel de procédure à distance (RPC)


Thread
OS+ protocoles de communication
L’architecture d’environnement de
développement d’application distribuée
 Threads : supporte la création, la gestion et la
synchronisation des programmes.
 RPC: outil composé d’un langage et son compilateur
qui génère un code qui transforme les appels de
procédure distant en message.
 Service de répertoire : service d’annuaire qui établit la
correspondance ente l’identifiant logique et physique
des programmes manipulés.
 Service de temps distribué: fournit à toutes les
machines une référence temporelle commune.
L’architecture d’environnement de
développement d’application distribuée
 Service de sécurité : communication sécurisés et
contrôle d’accès.
 Service de fichiers distribués: permet d’accéder et
de partager des fichiers n’importe où dans le réseau
sans se préoccuper de leur localisation physique.
Relation avec le réseau et le SE
 Service réseau :
 Couche de transport TCP ou UDP accédée via socket.
 Adressage IP.
 Identification d’un nœud sur le réseau.
 Identification d’un processus (un IP, un port, un clé)

 Service SE :
 La multitâche.
 La gestion de délai (timer)
 Les communications locales inter-processus.
 Gestion de mémoire …
Les Threads (1/2)
 Un thread : flot de contrôle séquentiel indépendant
associé à un processus.
 Permet de développer des programmes dans lesquels
plusieurs flots de contrôle peuvent être spécifiés.
 Améliorer la performance
 Permet une meilleur structuration de l’application.
Espace d’adressage Espace d’adressage
Programme classique Programme multi-threads
thread thread thread thread
Les Threads (2/2)
 Un thread possède:
 son propre identificateur
 Une politique et une priorité d’ordonnancement
 Une partie privée:
 Pile d’exécution, valeurs de registres, mémoire locale,
variable errno
 Les appels systèmes de Lunix retrouvent leur état d’erreur dans
une variable globale errno
 Une partie partagée : texte du programme, fichiers
ouverts, sockets
Les Threads: problèmes (1/2)
 Problèmes au niveau du traitement des signaux:
 Signal synchrone : généré par le thread actif suite à une erreur (division
par 0)
 Processus actif tué.
 Signal asynchrone : généré par un processus externe
 Mécanisme de gestion des signaux.
 Problème de cohérence
 Thread 1 est entrain d’allouer de la mémoire lorsqu’il y a un
changement de contexte => les structures internes de l’allocateur de
mémoire ne sont pas cohérent.
 Ajout de quelque procédures qui représentent des enveloppes garantissant un
accès en exclusion mutuelle.
Les Threads: problèmes (2/2)
 Gestion d’erreur:
 Un thread effectue un appel système puis un autre
appel système est lancé par un autre thread => la
variable errno originale est perdue.
 L’ajout d’une interface de gestion des variables
d’erreurs.
La synchronisation des threads:
Exemples
 Entrelacements possible lors de l’exécution de Action_P et Action_Q.

Section critique:
pas d’accès
concurrent à cette
section

Section critique
atomique
La synchronisation des threads
 Processus en concurrence pour l’utilisation des ressources:
 Ressources physiques: processeur, disque …
 Ressources logiques: zones mémoires partagées, fichiers,
services, …
 Contrôler la concurrence:
 Organiser la compétition:
 Service système de synchro : arbitrage par exclusion mutuelle.
 Inclure la partie contrôle dans les programmes concurrents : sans
arbitrage.
 Organiser l’utilisation des ressources:
 Empêcher ou réparer les interblocages (deadlock).
 Garantir l’équité ou l’absence de famine.
La synchronisation des threads
Niveau d’abstraction Niveau d’abstraction haut:
bas : section critique transaction atomique
.

Problème : accès
concurrents aux ressources
communes
La synchronisation des threads
(thread java)
 Extension de la classe Thread
 méthode run est le code qui sera exécuté.
 la création d'un objet dont la superclasse qui crée la
thread (mais ne la démarre pas)
 La méthode start démarre la thread (et retourne
immédiatement)
 la méthode join permet d'attendre la fin de la thread
 les exécutions des threads sont asynchrones et
concurrentes
La synchronisation des threads
(thread java)
class ThreadAffiche extends Thread{ public static void main(String[] arg)
private String mot; {
private int delay; new ThreadAffiche("PING",
public ThreadAffiche(String w,int 10).start();
duree){ new ThreadAffiche("PONG",
mot=w; 30).start();
delay=duree; new
} ThreadAffiche("Splash!",60).start();
public void run(){ }}
try{
for(;;){
System.out.println(mot);
this.sleep(delay);
}
}catch(InterruptedException e){}
}
}
La synchronisation des threads
(thread java)
 Les threads s'exécutent concurremment et peuvent
accéder concurremment à des objets:
class X{int val;}
class Concur extends Thread{
X x; int i; String nom;
public Concur(String st, X x){
nom=st;
this.x=x;}
public void run(){
i=x.val;
System.out.println("thread:"+nom+" valeur x="+i);
try{
Thread.sleep(10);
}catch(Exception e){}
x.val=i+1;
System.out.println("thread:"+nom+" valeur x="+x.val);
}}
La synchronisation des threads
(thread java)
public static void main(String[] args) {
X x=new X();
Thread un=new Concur("un",x);
Thread deux=new Concur("deux",x);
un.start(); deux.start();
try{
un.join();
deux.join();
}catch (InterruptedException e){}
System.out.println("X="+x.val);
}
donnera (par exemple)
thread:un valeur x=0
thread:deux valeur x=0
thread:un valeur x=1
thread:deux valeur x=1
X=1
La synchronisation des threads
(thread java)
 à chaque objet est associé un verrou
 synchronized(expr) {instructions}
 expr doit s'évaluer comme une référence à un objet
 verrou sur cet objet pour la durée de l'exécution
des instructions
 déclarer les méthodes comme synchronized: le
thread obtient le verrou et le relâche quand la
méthode se termine
La synchronisation des threads
(thread java)
class Concur extends Thread{
X x;
int i;
String nom;
public Concur(String st, X x){
nom=st;
this.x=x;
}
public void run(){
{
i=x.val;
System.out.println("thread:"+nom+" valeur x="+i);
try{
Thread.sleep(10);
}catch(Exception e){}
x.val=i+1;
System.out.println("thread:"+nom+" valeur x="+x.val);
}}}
La synchronisation des threads
(SE)
 Synchroniser des threads en exclusion mutuelle:
 L’exclusion mutuelle: primitive de synchronisation
pour éviter l’accès simultané à une ressource.
 Variable d’exclusion mutuelle: mutex
 Structure complexe : propriétaire, type du mutex, verrou
La synchronisation des threads
(thread java)
 la synchronisation par des verrous peut entraîner un
blocage:
 le thread un (XA) pose un verrou sur l'objet A et
demande un verrou sur l'objet B le thread deux (XB) pose
un verrou sur l'objet B et demande un verrou sur l'objet A

 Ni XA ni XB ne peuvent être satisfaites -> blocage


(deadlock)
RPC
 Étendre l’appel de procédure local à un appel distant
 Cacher les détails de la programmation distribuée

 Le talon coté client intercepte les appels du programme


client et effectue le transfert de message vers le talon
serveur.
RPC
 Problème : comment localiser le programme serveur:
 Étape 1 : Localiser la machine serveur (annuaire).
 Étape 2 : localiser le bon processus sur cette machine (démon
RPC)
RPC
 Indépendance du langage
 Indépendance de la représentation des données
 Indépendance du protocole (à noter au niveau de
l’annuaire).
 Indépendance de la machine
 Indépendance du système d’exploitation (pas
d’appel système).
Le Service de Temps Distribué
(DTS)
 Une architecture distribuée doit utiliser des
horloges synchronisées.
Le Service de Temps Distribué
(DTS)
 Une horloge n’utilise pas un temps continu
 Utilisation de top d’horloge.
 Les tops d’horloge dérivent de quelques ms toutes les
heures
 Solution : essayer d’arriver à un consensus:
 consulter plusieurs horloge et calculer la moyenne.
 DTS adopte un protocole de mise à jour d’horloges
d’une architecture distribuée.
 Horloges cohérentes
 Horloges en contact avec la réalité
Le Service de Temps Distribué
(DTS)
 Le DTS contient les composants suivants:
 Le time clerck (employé du temps): fonctionne coté client,
synchronise l’horloge locale en demandant l’heure corrigé au
serveur de temps.
 Le serveur de temps: nœud désigné pour répondre aux
questions à propos du temps.
 S: serveur de temps, C : cellule.
Le Service de Temps Distribué
(DTS)
 On distingue plusieurs types de serveur de temps :
 Serveur de temps local (S),Serveur de temps global (G)
 Serveur de temps messager (courrier Co)
 Serveur de temps messager de secours
Le transactionnel réparti
 Applications réparties= ensemble de sites.
 Chaque sites comprend une plateforme avec:
 Des modules d’acquisition : captures concurrentes, acquisition
synthétique.
 Des bases de données : lecteurs, rédacteurs en mémoire centrale.
 Messagerie : producteurs/consommateurs: modèle publier/souscrire.
 Module réseau : communication de messages intersites des
processus de service.
 Une couche applicative avec des processus appelés transactions
applicatives.
Exemple
 Application au système bancaire
 Modèle de données (objets)
 Type Client Type Compte
Nom : chaîne Numéro : entier
Adresse : chaîne Solde : réel
Comptes : liste de compte
 Modèle de comportement (opérations)
 Opération simple sur un objet :
 Créditer(Compte_à_créditer, Montant)
 Débiter(Compte_à_débiter, Montant)
Exemple
 Opération complexe sur plusieurs objets
 Virement(Compte_à_débiter, Compte_à_créditer,Montant)
Problématiques (1/2)
 Applications coopératives:
 Transactions avec accès emboités à plusieurs BD :
 Problèmes de cohérence globale et interblocage.
 Copies multiples d’une même BD avec écritures sur chaque
copie:
 Cohérence faible (problème de caches multiples)
 Problème de synchronisation entre les transactions
coopérantes :
 Démarrage dans un état cohérent.
 Coordination par un site fixe
 Si absent (panne, maintenance) élection d’un nouveau coordinateur
 Terminaison de la coopération
Problématiques (2/2)
 Points de reprise cohérents.
 Diffusion fiable et ordonnée à un groupe de processus
sur des sites divers.
 Mobilité des sites.
Hypothèses
 Tout message arrive avant le délai dmax, qu'il soit point à point ou
diffusé.
 Communication fiable : pas de perte de message, pas de panne de
site
 Réseau connexe : tout site peut communiquer avec tous les autres
 parfois réseau isotrope : même délai dmax pour tous les canaux
 Les horloges des sites sont aussi synchronisées(leur écart est
borné par dhmax)
 Les vitesses des processeurs sont supérieures à un minorant connu
Cohérence et transaction
 Objectif
 Donner un moyen simple de préserver la cohérence des
informations manipulées par des activités concurrentes
 Transaction atomique:
 permet d'isoler chaque activité des effets dûs à la
concurrence et aux pannes.
 très utilisée dans le domaine des bases de données
centralisées et réparties, mais aussi dans les systèmes
d'exploitation répartis tolérant les pannes.
Cohérence et transaction
 Deux aspect importants:
 Le contrôle de concurrence = permet de synchroniser
(coordonner) les activités parallèles de plusieurs
applications (transactions) et accède à des objets
partagés,
 La reprise arrière = mécanisme système de sauvegarde
qui assure que les pannes ne peuvent corrompre les
données persistantes.
Cohérence et transaction
 Sécurité et protection : les informations sensibles ou
confidentielles doivent être protégées des accès non
autorisés.
 Cohérence sémantique : les informations enregistrées
dans le système doivent être conformes à la sémantique
de l'application (solde>0)
 Redondance et transactions : les informations doivent
être protégées des événements externes tels que les
défaillances ou le partage incontrôlé
Cohérence et transaction
 Défaillances : processus avorté avant sa terminaison,
panne d'un support persistant.
 Dans l'opération de virement, un compte a été débité, alors
que l'autre n‘a pas été crédité

 Partage incontrôlé : accès concurrent à une même


donnée.
 Exécution concurrente de plusieurs transferts de fond sur
des comptes partagés

Vous aimerez peut-être aussi