Exclusion mutuelle Synchronisation avancée. Programmation parallèle et concurrente

Transcription

1 Exclusion mutuelle Synchronisation avancée Programmation parallèle et concurrente

2 Problématique Synchronisation = essentielle si utilisation de plusieurs threads Développement d'applications robustes 2

3 Un problème classique de synchronisation Plusieurs problèmes de synchronisation se posent ici : 1. Plusieurs récepteurs ne peuvent pas déposer simultanément un travail dans la file des travaux, sinon les travaux seraient sur la même case ; 2. Si la file des travaux est pleine, les récepteurs doivent attendre qu'une case se libère pour déposer un nouveau travail ; 3. Plusieurs ouvriers ne peuvent pas prendre chacun un travail simultanément, sinon ils auraient le même travail à traiter ; 3

4 Un problème classique de synchronisation 4. Si la file des travaux est vide, les ouvriers doivent attendre qu'un travail soit déposé pour pouvoir le traiter ; 5. Plusieurs ouvriers ne peuvent pas déposer simultanément le résultat d'un travail dans la file des résultats, sinon les résultats seraient sur la même case ; 6. Si la file des résultats est pleine, les ouvriers doivent attendre qu'une case se libère pour déposer un nouveau résultat ; 7. Si la file des résultats est vide, l'émetteur doit attendre qu'un résultat soit disponible. 4

5 Un problème classique de synchronisation But : résoudre ces problèmes généraux (auxquels on peut généralement se ramener) Pour les résoudre correctement, il faut assurer : La sûreté : rien de mauvais ne se produit, quelque soit l'entrelacement des threads (deux ouvriers ne peuvent jamais prendre le même travail) ; La vivacité : quelque chose de bon finit par se produire (si la file des travaux n'est pas vide, un ouvrier finira par prendre les travaux). Il faut aussi prendre en compte les cas possibles ; par exemple, deux travaux déposés consécutivement peuvent être exécutés séquentiellement par le même ouvrier. 5

6 Exclusion mutuelle de sections critiques Exclusion mutuelle permet de résoudre les problèmes 1, 3 et 5 Avant de regarder un exemple, quelques définitions 6

7 Sections critiques Etant donnée du code, on peut y définir des portions particulièrement importantes que l'on dénote par sections critiques. Exemple : manipulation d'une variable partagée. // Du code... /* Section Critique */... // variable partagée /* Fin de la Section Critique */ // Encore du Code... 7

8 Exclusion mutuelle Solution : interdire la modification de données partagées à plus d un thread à la fois Exclusion mutuelle sur les sections critiques 4 conditions doivent être respectées : Deux threads ne doivent pas entrer dans la même section critique simultanément Aucune hypothèse sur le nombre de processeurs et sur la vitesse des threads Aucun thread suspendu en dehors d'une section critique ne doit bloquer les autres threads Aucun thread ne doit attendre trop longtemps avant d'entrer dans une section critique 8

9 Exclusion mutuelle Toute demande doit être satisfaite : Pas de famine Pas d'inter-blocage 9

10 Exclusion mutuelle de sections critiques Exemple : class ListeTab { private String[] tab = new String[50]; private int index = 0; void ajoute (String s) { tab[index] = s; index++; 10

11 Exclusion mutuelle de sections critiques void ajoute (String s) { tab[index] = s; //(a1) index++; //(a2) void ajoute (String s) { tab[index] = s; //(b1) index++; //(b2) 2 threads Ta et Tb exécutent en parallèle (ou en pseudoparallèle sur un mono-processeur) la fonction ajoute(string) sur la même ListeTab Exécutions possibles : (a1) (a2) (b1) (b2), est une exécution possible, cohérente ; (b1) (b2) (a1) (a2), est une exécution possible, cohérente ; (a1) (b1) (b2) (a2), est une exécution possible, mais incohérente : le tableau ne contient pas la chaîne de caractères ajoutée par Ta, et une case de la liste est vide. 11

12 Exclusion mutuelle de sections critiques Ce problème récurrent peut être résolu par l'exclusion mutuelle (mutex) Fonction "ajoute" = section critique Plusieurs sections critiques dépendantes ne doivent jamais exécuter leur code simultanément (elles sont en exclusion mutuelle) Mise en place de l'exclusion mutuelle : utilisation de verrous Une section critique est vue comme une opération atomique 12

13 Mot-clé synchronized Pour faire cela en Java : synchronized synchronized(unobjet) { //section critique Cas particulier : synchronized void methode() { //section critique void methode() { synchronized(this) { //section critique 13

14 Package java.util.concurrent.locks Autre méthode pour réaliser des verrous, apparue dans Java 1.5 Exemple basique : Lock l = new ReentrantLock(); l.lock(); try { //section critique finally { l.unlock(); 14

15 Synchronisation coopérative Synchronisation coopérative : problèmes de synchronisations 2, 4, 6 et 7 Ils communiquent 15

16 Communication inter-threads Pas de scrutation entre threads. Pas de perte des cycles CPU à attendre un autre. Mécanisme de communication inter-threads accessible à travers 3 méthodes : (Devant être appelées depuis l'intérieur d'une méthode ou d'un bloc synchronized) wait() : fait sortir le thread appelant du moniteur et le met en sommeil jusqu à ce qu un autre thread entre dans le même moniteur et appelle notify() notify() : réveille le premier thread ayant appelé wait() sur le même objet notifyall() : réveille tous les threads ayant appelé wait() sur le même objet ; le thread de priorité la plus élevée s exécutera en premier. 16

17 Communication inter-threads Ces méthodes sont implantées dans Object. Toutes les classes en disposent. Rappel : ces 3 méthodes ne peuvent être appelées qu à l intérieur d une méthode synchronisée. Leur déclaration est : final void wait() final void notify() final void notifyall() Il y a également la forme final void wait(long timeout) qui permet d attendre un nombre donné de millisecondes. 17

18 Méthodes de la classe Object Exemple class ListeTab { private String [] tab = new String[50]; private int index = 0; synchronized void ajoute(string s) { tab[index] = s; index++; notify(); System.out.println("notify() exécuté"); 18

19 Méthodes de la classe Object Exemple synchronized String getpremierelementbloquant() { //tant que la liste est vide while (index == 0) { try { //attente passive wait(); catch(interruptedexception ie) { ie.printstacktrace() ; return tab[0] ; 19

20 Méthodes de la classe Object Exemple Limites : si section critique doit être synchronisée sur plusieurs verrous class UneClasse { private final Object lock1 = new Object(); private final Object lock2 = new Object(); void methode() { synchronized(lock1) { synchronized(lock2) { while (condition) { lock2.wait(); void notifie() { lock2.notify(); 20

21 Package java.util.concurrent.locks Solution : locks Principe : un seul verrou, plusieurs variables condition 21

22 Package java.util.concurrent.locks class UneClasse { private final Lock lock = new ReentrantLock(); private final Condition cond1 = lock.newcondition(); private final Condition cond2 = lock.newcondition(); void methode1() throws InterruptedException { lock.lock(); try { cond2.await(); cond1.signal(); finally { lock.unlock(); 22

23 Package java.util.concurrent.locks void methode2() throws InterruptedException { lock.lock(); try { cond1.await(); cond2.signal(); finally { lock.unlock(); 23

24 Sémaphores Classe Semaphore : apparue dans Java 1.5 Un sémaphore encapsule un entier, avec une contrainte de positivité, et deux opérations atomiques d'incrémentation et de décrémentation variable entière (toujours positive ou nulle). opération P (acquire()) : décrémente le compteur s'il est strictement positif ; bloque s'il est nul en attendant de pouvoir le décrémenter. opération V (release()) : incrémente le compteur. 24

25 Sémaphores Exemple : Semaphore sem = new Semaphore(1); try { sem.acquire(); //section critique sem.release(); catch (InterruptedException e) { e.printstacktrace(); Exercice : Ecrire votre propre classe sémaphore (sans utiliser Semaphore) avec wait(), notify(),... 25

26 Solutions implantées dans l'api 1.5 Package java.util.concurrent Liste bloquante : BlockingQueue et ArrayBlockingQueue (liste bloquante à tampon borné) Outil très utile : Executor Liste d'attente bloquante d'actions à effectuer 26

27 Solutions implantées dans l'api 1.5 Exemple d'utilisation d'executor : Executor executor = Executors.newSingleThreadExecutor(); executor.execute(new Runnable() { public void run() { System.out.println ("appel asynchrone 1"); ); executor.execute(new Runnable() { public void run() { System.out.println ("appel asynchrone 2"); ); 27

28 Inter-blocage Exemple très simple d'inter-blocage class DeadLock { private final Object lock1 = new Object(); private final Object lock2 = new Object(); void a() throws InterruptedException { lock1.wait(); lock2.notify(); void b() throws InterruptedException { lock2.wait(); lock1.notify(); 28

29 Définitions Thread-safe : utilisation sûre dans un environnement multi-threads. Un objet est immutable s'il n'est jamais modifié après sa construction. Rappel : final Un objet immutable est toujours thread-safe Confinement : consiste à ne laisser accessible un objet que par un seul thread. 29

30 Éviter la synchronisation inutile Synchronisation : chose essentielle Mais coûte cher en ressources Bien concevoir vos programmes Voir si le modèle d'une file d'attente unique ne convient pas mieux (Executor) Eviter les anciennes collections (Vector, Hashtable, ), préférer ArrayList, HashMap, 30

31 Annexe 31

32 Outils pour la concurrence Structures de données classiques à protéger déjà synchronizés optimisées pour la concurrence Objets atomiques Primitives de synchronisation Préférez les structures de données existantes.... et seule la javadoc fait foi. 32

33 Collections non synchronisées A protéger avec synchronized(objet)! Interface List<E> : listes ArrayList<E> LinkedList<E> CopyOnWriteArrayList<E> : threadsafe mais modifications très coûteuses. Interface Set<E> : ensembles HashSet<E> TreeSet<E> CopyOnWriteSet<E> : threadsafe mais modifications très coûteuses. attention si les éléments sont mutables... Interface Map<K,V> : table d'association clef-valeur. HashMap<K,V> TreeMap<K,V> ordonné 33

34 Collections synchronisées L'implémentation de ces objets utilisent des verrous (implicites). Vector<E> : "tableau dynamique" boolean add(e elt) : ajoute elt en fin de tableau, boolean add(int i,e elt) : ajoute elt en position i du tableau, E get(int index) : renvoie l'élément en position i du tableau, boolean remove(e elt) : retire la première occurrence de elt, retourne vrai s'il y en a une, E remove(int i) : retire l'élément en position i et retourne celui-ci. Stack<E> extends Vector<E> : pile E peek() : renvoie le premier élément de la pile sans l'enlever, E pop() : renvoie le premier élément de la pile et l'enlève de celle-ci, E push(e elt) : met elt sur la pile et retourne elt Hashtable<K,V> : table de hachage V get(object clef) : renvoie l'objet indexé par clef, V put(k clef, V valeur) : associer valeur à clef dans la table. 34

35 Itérateurs et accès concurrents Depuis Java 1.5, il est possible d'utiliser des "itérateurs" : Vector<E> liste; for(e elt : liste) elt.traitement(); Les objets et méthodes précédentes sont à "défaillance rapide" : si une modification simultanée est détectée lors de l'utilisation d'un itérateur, l'exception ConcurrentModificationException est reçue. à utiliser uniquement pour détecter les problèmes, pas un mécanisme de gestion de la concurrence. 35

36 java.util.concurrent Il est à la fois pénible et source d'erreurs de recoder des primitives de synchronisation de haut niveau java.util.concurrent Collections spécialisées : BlockingQueue Objets thread-safe mais sans verrous Implémentation efficace de variables atomiques Outils de synchronisation Verrous (avec timeout) Granularité temporelle à la nanoseconde System.nanotime Environnement d'ordonnancement de tâches : Executor et Callable 36

37 Interface BlockingQueue<E> Implémentations de files d'attente bloquantes (i.e. les accès bloquent si la file est vide ou pleine) ArrayBlockingQueue<E> file de taille bornée ArrayBlockingQueue(int capacite) construit une file de taille capacite, ArrayBlockingQueue(int capacite, boolean fair) construit une file de taille capacite et équitable : les accès sont FIFO, void put(e elt) ajoute elt à la file, en attendant si celle-ci est pleine, E take() renvoie le premier élément de la file et le retire, en bloquant tant que la file est vide, E poll(long delai, TimeUnit unit) renvoie le premier élément de la file et le retire, en attendant au plus delai unit, offer(e elt) ajoute elt à la file, en attendant retournant immédiatement sans ajouter si la file est pleine. 37

38 Interface BlockingQueue<E> LinkedBlockingQueue<E> file optionnellement bornée LinkedBlockingQueue() crée une file d'attente (de taille maximale Integer.MAX_VALUE), LinkedBlockingQueue(int capacite) crée une file d'attente de taille maximale capacite éléments, et méthodes identiques. SynchronousQueue<E> file de capacité nulle rendez-vous. SynchronousQueue() SynchronousQueue(boolean fair), avec accès FIFO si fair est vrai, Même méthodes. 38

39 ConcurrentLinkedQueue<E> Une file d'attente non bornée, thread-safe et sans attente. boolean add(e elt) ajoute elt et renvoie true, E poll() retourne et enlève le premier élément de la file, E peek() retourne sans enlever le premier élément de la file. Très appropriée à un environnement multi-threads. 39

40 ConcurrentHashMap<K,V> Table de hachage pour accès concurrents : threadsafe, sans verrous (bon débit), impossible de verrouiller (synchronized) l'accµes µa toute la table, pas de ConcurrentModificationException avec les itérateurs même si ceux-ci sont prévus pour être mono-threads "consistance faible" size() et isempty() renvoie des résultats "approchées" synchronisation induite moindre. ConcurrentHashMap(int capinitiale, float facteurcharge, int niveauconcurrence) crée une table de capacité initiale capinitiale, avec facteurcharge de paramètre de rééquilibrage interne dynamique, et pour environ niveauconcurrence threads modifiant la table simultanément. les rééquilibrages internes sont coûteux. Remplace très avantageusement Hashtable en général. 40

41 Que Choisir? Objets synchronisés (bloquants ou potentiellement bloquants) vs concurrents (non bloquants)?? Paramètres débit de traitement taux de concurrence type de traitement intensif en E/S intensif en CPU prévisibilité de comportement Bien lire les documentations et bien modéliser le problème (combien de threads modifient la structure, combien ne font que lire, problèmes de débit...) 41

42 Variables Atomiques C'est une généralisation de volatile : AtomicBoolean, AtomicInteger, AtomicLong, AtomicReference, AtomicLongArray, AtomicReferenceArray. 42

43 Accès aux Variables L'accès est thread-safe et sans inter-blocages get : renvoie la valeur, set : affecte la valeur, Ces opérations utilisent des instructions de très bas niveau et sont donc sujettes à variations selon les plateformes (et notamment ne sont pas, à strictement parler, non bloquantes). 43

44 Opérations Particulières Il s'agit d'opérations combinant, de manière atomique, un test et une affectation éventuelle (ici, dans le cas d'un AtomicLong) : boolean compareandset(long expect, long update) : teste l'égalité de la valeur avec expect et affecte update dans le cas positif. Revient à lire puis écrire un volatile boolean weakcompareandset(long expect, long update) : idem, sauf que l'accès n'est séquentialisé que cet objet long getandset(long newvalue) : affecte à la nouvelle valeur et renvoie l'ancienne long getandincrement() : incrémente de manière atomique long getanddecrement() : décrémente de manière atomique long incrementandget() : incrémente de manière atomique long decrementandget() : décrémente de manière atomique long getandadd(long delta) : ajoute delta atomiquement 44

45 La Classe CyclicBarrier Une barrière est un système permettant de bloquer un thread en un point jusqu'à ce qu'un nombre prédéfini de threads atteigne également ce point. La barrière est cyclique car elle est "réutilisable". Pour une barrière utilisée une seule fois, préférer CountDownLatch (voir plus loin). CyclicBarrier(int parties) : barrière pour parties threads, CyclicBarrier(int parties, Runnable barrieraction) : barrière pour parties threads, barrieraction est exécutée avant de lever la barrière. 45

46 Méthode await int await() : attendre que tous les threads aient atteint la barrière ou que l'un des threads en attente soit interrompu l'un des threads en attente atteigne son délai d'attente la barrière soit réinitialisée int await(long timeout, TimeUnit unite) : idem avec un délai d'attente de timeout valeur de retour : ordre inverse d'arrivée à la barrière, i.e. le nombre de threads restant à attendre. 46

47 Méthode reset int getnumberwaiting() : renvoie le nombre de threads en attente sur la barrière. pour déboguer void reset() : réinitialise la barrière (les éventuels threads en attente reçoivent BrokenBarrierException) Si une barrière est interrompue autrement que par reset() et BrokenBarrierException, il est difficile de la réinitialiser correctement. Dans ce cas, il est conseillé de créer une nouvelle barrière. 47

48 Utilisation d'une barrière // une seule fois CyclicBarrier barriere = new CyclicBarrier(N); // pour chaque thread... try { barriere.await(); catch (InterruptedException ex) { return ; catch (BrokenBarrierException ex) { return ; // réinitialisation de la barriµere barriere.reset(); 48

49 CountDownLatch Attente sur des événements ("compte à rebours") et non plus sur l'arrivée d'autres threads. CountDownLatch(int n) crée une barrière de n éléments, void await() attendre que le compte µa rebours soit terminé, void await(long delai, TimeUnit unit) attendre au plus delai unit que le "compte à rebours" soit terminé, void countdown() décrémente le compteur. Si 0 est atteint, tous les threads bloqués sont libérés, long getcount() renvoie l'état du compteur. 49

50 Architecture Executor Executor : permet découpler ce qui doit être fait de quand et comment le faire explicitement. Tâches à exécuter Pool de threads : réutilisation de threads schémas producteurs/consommateurs Contraintes d'exécution : dans quel thread exécuter quelle tâche? dans quel ordre (FIFO,LIFO, par priorité)? combien de tâches peuvent être exécutée concurremment? combien peuvent être mises en attente? en cas de surcharge, quelle tâche sacrifier? gestion de ressources 50

51 Pools Méthodes statiques de Executors : ExecutorService newfixedthreadpool(int n) : renvoie un pool de taille fixée n, rempli par ajout de threads jusqu'à atteindre la limite, les threads qui meurent sont remplacés au fur et à mesure, ExecutorService newcachedthreadpool() : renvoie un pool dynamique qui se vide ou se remplit selon la charge, ExecutorService newsinglethreadpool() : renvoie un pool contenant un seul thread ( séquentialisation), remplacé en cas de mort inattendue, ExecutorService newscheduledthreadpool(int n) : renvoie un pool de taille fixée n qui peut exécuter des tâches avec délai ou périodiquement. 51

52 ExecutorService et cycle de vie d'une tâche Une tâche est successivement pas commencée en cours s'arrêtant terminée. void shutdown() : arrêt "propre", aucune nouvelle tâche ne peut être acceptée mais toutes celles soumises sont exécutées, List<Runnable> shutdownnow() : tente d'arrêter les tâches en cours (par InterruptedException) et renvoie la liste des tâches soumises mais n'ayant pas débuté, 52