Introduction : les processus. Introduction : les threads. Plan

Transcription

1 IN328 Programmation distribuée avec Java et J2EE 2 - Threads en Java Introduction : les processus Un processus est un ensemble d instructions à exécuter, un espace mémoire réservé et éventuellement d autres ressources (sockets, fichiers, etc). Les systèmes d exploitation actuels permettent d exécuter «en même temps» plusieurs processus et de les ordonnancer. Christophe Garion ISAE/DMIA - SUPAERO/IN 10 avenue Édouard Belin Toulouse Cedex 4 OS Proc. 1 Local mem. Proc. 2 Local mem. Proc. 3 Local mem. Christophe Garion IN Threads 1/ 49 Introduction : les threads Thread est une abréviation de thread of control : fil de contrôle. On parle aussi de processus léger. Un thread est exécuté dans un processus. Il partage un espace mémoire avec les autres threads du processus. Les processus partagent rarement un espace mémoire. Ils ont une pile, un espace d adressage propres. Plan 1 Présentation des threads OS Proc. 1 Local mem. JVM Local mem. Proc. 2 Thread 1 Thread 2 Local mem. Local var. Local var. 2 Communication entre threads Synchronisation, verrous et interblocage La classe BusyFlag Interaction entre threads 3 Collections et java.util.concurrent Applications : entrées/sorties non bloquantes, multi-processeurs, timer, alarme, algorithmes parallélisables etc. Christophe Garion IN Threads 4/ 49

2 Threads en Java : un exemple Animation d un composant graphique : import javax.swing.*; public class TimerThread extends Thread { JComponent comp; int timediff; boolean shouldrun; // le composant a redessiner // le temps entre chaque rafraichissement // mettre a false pour arreter le thread public TimerThread(JComponent comp_, int timediff_) { comp = comp_; timediff = timediff_; shouldrun = true; public void run() { while(shouldrun) { comp.repaint(); sleep(timediff); catch(interruptedexception e) { e.printstacktrace(); Utilisation de l interface Runnable On peut également utiliser l interface Runnable : public interface Runnable { public void run(); Dans ce cas, on peut créer un thread en utilisant le constructeur Thread(Runnable r) : Thread t = new Thread(runnable); t.start(); Avantages : évite d utiliser une relation d héritage ; permet de manipuler directement des attributs en écrivant la méthode run directement dans une classe «intéressante». Inconvénient : complexité accrue des classes. Christophe Garion IN Threads 8/ 49 API des threads en Java Principe On étend la classe Thread qui est la classe de «base». Des méthodes : run() décrit le flot d exécution du thread. On peut la comparer à la méthode main du programme principal ; sleep(long milliseconds) permet de mettre en sommeil le thread courant pendant une durée de milliseconds ms. Exemple : Thread.currentThread().sleep(5000); Exemple d utilisation du thread précédent : TimerThread timer = new TimerThread(comp, 50); timer.start(); start lance le thread en appelant sa méthode run. La méthode start retourne immédiatement. Le thread s exécute donc en parallèle ; l arrêt du thread est provoqué par le passage de shouldrun à false. Le thread a alors fini sa méthode run. Christophe Garion IN Threads 7/ 49 Le cycle de vie d un thread start() NEW RUNNABLE WAITING fin de run() travaille TERMINATED TIMED WAITING BLOCKED Le thread est WAITING lors d un appel à wait ou join (ou TIMED_WAITING pour sleep ou versions temporisées de wait et join). Le thread est BLOCKED en attente de verrou. À partir de la version 5.0 de Java, on dispose de la méthode getstate() permettant de trouver l état d un thread. Christophe Garion IN Threads 9/ 49

3 Communication basique entre threads La méthode public boolean isalive() permet de savoir si un thread est encore en vie. Communication basique entre threads La méthode join() (et ses variantes) sur un thread permet d «attendre» qu un thread se finisse : état démarré isalive() public class Calcul implements Runnable { public void run() {... //gros calcul non démarré temps public class MiseEnFormeResultat { public static void main(string[] arg) { Thread t = new Thread(new Calcul()); t.start(); t.join(); afficherresultats(); Christophe Garion IN Threads 12/ 49 Synchronisation Le principal problème du partage de données entre threads est que plusieurs threads peuvent tenter d accéder aux même données en même temps. Exemple classique (voir cours bases de données) : une femme et son mari possèdent un compte commun. Ils retirent de l argent en même temps : 1 le mari demande un retrait ; 2 ce retrait est autorisé (montant disponible sur le compte) ; 3 la femme demande un retrait ; 4 ce retrait est autorisé (montant disponible sur le compte) ; 5 le retrait du mari est pris en compte et il reçoit l argent ; 6 le retrait de la femme est pris en compte et elle reçoit l argent ; 7 la somme des montants des deux retraits n était pas autorisée. Christophe Garion IN Threads 13/ 49 Quelles opérations sont sûres en Java? Principe (atomicité) L affectation d une variable de type autre que double ou long est atomique. Par contre, les threads en Java peuvent partager des valeurs et en posséder une copie locale (cf. spécification du langage). On n est donc pas garanti que la valeur d une variable lue depuis un thread a pris en compte les changements effectués par un autre... On peut utiliser le mot-clé volatile pour préciser qu un attribut d une classe doit être «synchronisé» à chaque modification. Christophe Garion IN Threads 14/ 49 Christophe Garion IN Threads 15/ 49

4 Synchronisation : section critique Dans l exemple précédent, on va dire que la méthode retirer est une section critique (on parle aussi de race condition). Définition (section critique) Une section critique est une portion de code ne pouvant pas être exécutée simultanément par deux threads. Pour pallier ce problème, on peut utiliser différentes primitives de programmation concurrente : mutex sémaphore... Synchronisation : monitor Nous allons nous intéresser ici aux verrous mutex. Principe (verrou mutex) Un seul thread à la fois peut acquérir un verrou mutex. En Java, un verrou mutex est créé pour chaque objet du système (on l appelle également monitor). Le mot clé synchronized permet de spécifier qu une méthode ou un bloc de code nécessite l acquisition du verrou de l objet sur lequel on appelle la méthode. public class Compte { private float montant; public synchronized void debiter(float montant_) { // et hop on enleve de l argent Christophe Garion IN Threads 16/ 49 Synchronisation : acquisition et relâche du verrou public class Compte { private float montant; public synchronized void debiter(float montant_) { // et hop on enleve de l argent Christophe Garion IN Threads 17/ 49 Imbrication des verrous Remarque Il n y a pas de problème de verrous imbriqués. Si un thread possède un verrou sur un objet, alors l appel à une méthode synchronized de cet objet dans une méthode synchronized de ce même objet se déroule sans problème. Principe (acquisition/relâche des verrous) si un thread veut exécuter la méthode debiter, il doit obtenir le verrou de l objet de type Compte qu il manipule. lorsqu il l a, il exécute debiter. quand il a finit l exécution de debiter, il relâche le verrou sur l instance de Compte. Christophe Garion IN Threads 18/ 49 Christophe Garion IN Threads 19/ 49

5 Un exemple d utilisation des threads pour les I/O Les entrées/sorties sont souvent bloquantes. Voici un exemple d utilisation avec la lecture sur une socket (récupération et traitement de données par exemple) : import java.io.*; import java.net.*; public class AsyncReadSocket extends Thread { private Socket s; private StringBuffer result; public AsyncReadSocket(Socket s) { this.s = s; result = new StringBuffer(); Christophe Garion IN Threads 20/ 49 Interblocage Le fait de poser des verrous sur des objets peut amener des situations d interblocage (ou deadlock). Définition (interblocage) Un interblocage est une situation dans laquelle deux threads s attendent mutuellement pour obtenir une ressource. Exemple : le thread t1 possède le verrou sur l objet o1 ; le thread t2 possède le verrou sur l objet o2 ; pour continuer (et donc pour pouvoir libérer le verrou sur o1), t1 cherche à obtenir le verrou sur o2 ; de la même façon, t2 cherche à obtenir le verrou sur o1 ; les deux threads sont dans l état BLOCKED... Un exemple d utilisation des threads pour les I/O public void run() { DataInputStream is = null; is = new DataInputStream(s.getInputStream()); catch (Exception e) { // end of try-catch while (true) { char c = is.readchar(); appendresult(c); catch (Exception e) { // end of try-catch // end of while (true) public synchronized void appendresult(char c) { result.append(c); public synchronized String getresult() { String retval = result.tostring(); result = new StringBuffer(); return retval; Portée de synchronized : un exemple Considérons la classe suivante : public class C { Object ressource1; Object ressource2; public synchronized void m1() { // utilisation de ressource1 // mais pas de ressource2 public synchronized void m2() { // utilisation de ressource2 // mais pas de ressource1 Le problème de l interblocage provient souvent d une portée trop longue du synchronized (problème de la granularité dans les bases de données). Christophe Garion IN Threads 22/ 49 Christophe Garion IN Threads 23/ 49

6 Portée de synchronized : un exemple On aimerait que : 1 deux threads ne puissent pas appeler m1 en même temps sur le même objet ; 2 deux threads ne puissent pas appeler m2 en même temps sur le même objet ; 3 m1 et m2 puissent être appelées en même temps sur le même objet. L utilisation de synchronized permet de garantir les deux contraintes 1 et 2, mais pas 3... Portée de synchronized : bloc On peut utiliser synchronized non pas sur une méthode, mais sur un bloc de code en précisant l objet sur lequel on veut obtenir le verrou : public class C { Object ressource1; Object ressource2; public void m1() { synchronized(ressource1) { // utilisation de ressource1 // mais pas de ressource2 public void m2() { synchronized(ressource2) { // utilisation de ressource2 // mais pas de ressource1 Christophe Garion IN Threads 24/ 49 Encore des comptes bancaires... Supposons que nous ayons les classe suivantes représentant un compte et un distributeur de billets : public class Compte { private double solde; public synchronized boolean debiter(double m) { if (m > solde) { solde -= m; return true; return false; public synchronized double getsolde() { return solde; Christophe Garion IN Threads 25/ 49 Encore des comptes bancaires... public class ATM { private Compte c; public synchronized void login(compte c_) throws Exception { if (c!= null) { throw new Exception("Already logged in!"); c = c_; public synchronized void retirer(double m) { if (c.debiter(m)) { System.out.println("Voici vos " + m + " euros"); System.out.println("Retrait non autorise!"); public synchronized void balance() { System.out.println("Solde : " + c.getsolde()); Christophe Garion IN Threads 27/ 49 public synchronized void logoff() { c = null;

7 Distributeur de billets : problème On a utilisé des méthodes synchronized : Mais : deux threads ne peuvent pas débiter un compte et consulter son montant en même temps deux threads ne peuvent pas utiliser le même distributeur en même temps un thread mari se connecte à un distributeur et regarde le solde de son compte joint (300 ) ; un thread epouse se connecte à un autre distributeur et retire 200 sur le compte joint ; mari essaye de retirer 150 : c est refusé! Verrouiller le compte sur la session? Il faudrait pouvoir bloquer le compte durant toute la durée de la session sur le distributeur (et donc sur plusieurs méthodes). Nous allons construire une classe permettant de signifier qu un thread utilise une ressource. Cette classe possédera : un attribut identifiant le thread utilisant la ressource ; une méthode permettant à un thread de verrouiller la ressource. Si un thread n obtient pas la ressource, il essayera d obtenir la ressource jusqu à son obtention ; une méthode permettant au thread possédant la ressource de la libérer. Christophe Garion IN Threads 29/ 49 La classe BusyFlagDeadlock Christophe Garion IN Threads 30/ 49 Retour sur l exemple avec BusyFlagDeadlock public class BusyFlagDeadlock { public class CompteBusyFlagDeadlock { private Thread busyflag; public synchronized void getflag() { while(true) { if (busyflag == null) { busyflag = Thread.currentThread(); break; Thread.sleep(100); catch (Exception e) { public synchronized void libereflag() { if (busyflag == Thread.currentThread()) { busyflag = null; private double solde; private BusyFlagDeadlock bf = new BusyFlagDeadlock(); public synchronized boolean debiter(double m) { if (m < solde) { solde -= m; return true; return false; public synchronized double getsolde() { return solde; public synchronized void getflag() { bf.getflag(); public synchronized void libereflag() { bf.libereflag(); Christophe Garion IN Threads 31/ 49 Christophe Garion IN Threads 32/ 49

8 Retour sur l exemple avec BusyFlagDeadlock public class ATMBusyFlagDeadlock { private CompteBusyFlagDeadlock c; public synchronized void login(comptebusyflagdeadlock c_) throws Exception { if (c!= null) { throw new Exception("Already logged in!"); c.getflag(); c = c_; Interblocage? Avec la classe précédente, il y a quand même possibilité d interblocage : 1 mari appelle getflag(), obtient le verrou sur l objet BusyFlagDeadLock, l attribut busyflag change de valeur et mari libère le verrou ; 2 epouse appelle getflag(), obtient le verrou sur l objet BusyFlagDeadlock ; 3 comme busyflag n est pas null, t2 «reste» dans la boucle et conserve le verrou ; 4 mari appelle libereflag(), mais n obtient pas le verrou. public synchronized void logoff() { c.libereflag(); c = null; Il faut alors restreindre la portée de synchronized : ce sont juste les accès à busyflag qui nous intéressent. Christophe Garion IN Threads 33/ 49 Nouvelle version de BusyFlag public class BusyFlag { private Thread busyflag; public void getflag() { while(true) { synchronized (this) { if (busyflag == null) { busyflag = Thread.currentThread(); break; Thread.sleep(100); catch (Exception e) { public synchronized void libereflag() { if (busyflag == Thread.currentThread()) { busyflag = null; Christophe Garion IN Threads 34/ 49 Interblocage : problèmes sans solution? Donc on peut toujours s en sortir? Non : public void removeuseless(file file) { synchronized (file) { if (file.isuseless()) { Directory directory = file.getdirectory(); synchronized (directory) { directory.remove(file); public void updatefolders(directory dir) { synchronized (dir) { for (File f = dir.first(); f!= null; f.next()) { synchronized(f) { f.update(); Christophe Garion IN Threads 35/ 49 Christophe Garion IN Threads 36/ 49

9 Interblocage 1 un thread t1 appelle updatefolder et verrouille le dossier L1 ; 2 un thread t2 appelle removeuseless et verrouille le fichier F2 du dossier L1. Cette méthode détermine que F2 est inutile. Elle va donc chercher à obtenir le verrou sur L1 ; 3 dans le même temps, t1 va chercher à obtenir le verrou sur F2... Remarque Ces problèmes dépendent en plus de l OS, de la machine virtuelle etc. Solution On impose une hiérarchie «artificielle» de verrous : lors de l imbrication de synchronized, on choisira toujours le mutex d un même objet en premier. Christophe Garion IN Threads 37/ 49 Interaction entre threads : exemple du BusyFlag L instruction sleep(100) est problématique (perte de performances). Il faudrait pouvoir prévenir un thread en attente qu un événement se produit (par exemple que le BusyFlag vient d être libéré). L idée est donc la suivante : un thread peut avoir besoin qu une certaine condition soit réalisée pour continuer le traitement qu il doit effectuer. Cette condition peut être relâchée par un autre thread qui doit alors prévenir le premier. Il faut donc deux mécanismes : un mécanisme pour mettre en attente proprement un thread par rapport à une certaine condition ; un mécanisme pour prévenir un ou plusieurs threads en attente qu une condition est vérifiée. Cela rappelle fortement le pattern Observateur. Interaction entre threads : exemple du BusyFlag Reprenons l exemple du BusyFlag : public class BusyFlag { private Thread busyflag; public void getflag() { while(true) { synchronized (this) { if (busyflag == null) { busyflag = Thread.currentThread(); break; Thread.sleep(100); catch (Exception e) { public synchronized void libereflag() { if (busyflag == Thread.currentThread()) { busyflag = null; Les méthodes wait, notify et notifyall Pour réaliser tout cela, on dispose de trois méthodes disponibles sur toute instance de Object : void wait() : permet d attendre une condition. Elle doit être utilisée à l intérieur d un bloc ou d une méthode synchronized. Un thread qui appelle cette méthode doit posséder le verrou sur l objet en question (attention aux blocs synchronized!). Il passe alors en mode «dormant» et relâche le verrou. void notify() : notifie un thread en attente d une condition de la réalisation de cette condition. Elle doit être utilisée à l intérieur d un bloc ou d une méthode synchronized. Le thread doit avoir le verrou sur l objet. On ne choisit pas quel thread va être notifié (non précisé par la spécification de Java). void notifyall() : notifie tous les threads en attente sur un objet de l arrivée de la condition. Elle doit être utilisée à l intérieur d un bloc ou d une méthode synchronized. Christophe Garion IN Threads 40/ 49 Christophe Garion IN Threads 41/ 49

10 La classe BusyFlagWait public class BusyFlagWait { private Thread busyflag; public synchronized void getflag() { while(busyflag!= null) { wait(); catch (Exception e) { busyflag = Thread.currentThread(); Précisions sur la méthode wait lors de l entrée dans la méthode wait(), le verrou sur l objet synchronisé est relâché ; le verrou est repris juste avant la fin de la méthode wait ; la méthode wait est surchargée : void wait(long timeout). La méthode retourne après une durée de timeout millisecondes, même si aucune notification ne s est produite ; la différence fondamentale avec la méthode sleep est que le verrou est libéré dans le cas de l utilisation de wait ; il faut toujours placer la méthode wait dans une boucle infinie testant la condition de notification. public synchronized void libereflag() { if (busyflag == Thread.currentThread()) { busyflag = null; notify(); Christophe Garion IN Threads 42/ 49 Exemple avec BusyFlagWait 1 t1 appelle getflag(), obtient le verrou sur l objet BusyFlagWait, l attribut busyflag change de valeur et t1 libère le verrou ; 2 t2 appelle getflag(), obtient le verrou sur l objet BusyFlagWait ; 3 comme busyflag n est pas null, t2 exécute la méthode wait sur l objet dont il possède le verrou (ici l objet BusyFlagWait), passe en mode «dormant» et libère le verrou ; 4 t1 appelle libereflag(), obtient le verrou, l attribut busyflag passe à null ; 5 t1 appelle notify sur l objet BusyFlagWait dont il possède le verrou ; 6 t2 est prévenu. Il attend de pouvoir obtenir le verrou sur l objet ; 7 t1 libère le verrou en sortant de la méthode, t2 le récupère et revient au début de la boucle while ; 8 la valeur de busyflag est modifiée et t2 libère le verrou. Christophe Garion IN Threads 43/ 49 Interruption des threads Les méthodes wait, sleep et join peuvent lever une InterruptedException. Cette exception est levée lorsqu un thread appelle la méthode void interrupt() sur un autre thread : si le thread est bloqué dans une méthode comme wait, sleep ou join, alors ces méthodes lèvent une InterruptedException ; sinon un indicateur est positionné et le thread peut l examiner via la méthode static boolean interrupted() ou la méthode boolean isinterrupted(). On ne peut pas interrompre un thread qui est bloqué en attente d entrées/sorties (sauf sous certaines implantations comme les threads natifs sous Solaris). Christophe Garion IN Threads 44/ 49 Christophe Garion IN Threads 45/ 49

11 Les collections en Java Les collections en Java ne sont pas thread safe : on ne peut pas y accéder en même temps (même via des itérateurs). Il existe toutefois deux (anciennes) collections synchronisées : Vector Hashtable On peut toutefois obtenir une collection «synchronisée» en utilisant des méthodes statiques de la classe Collections : public static <T> Collection<T> synchronizedcollection(collection<t> c) public static <T> Set<T> synchronizedset(set<t> s) public static <K,V> Map<K,V> synchronizedmap(map<k,v> m)... Le paquetage java.util.concurrent Depuis Java 5.0, on a à disposition un paquetage contenant des interfaces et classes utilitaires implantant un certain nombre de solutions de synchronisation etc. lancement et gestion de tâches asynchrones via Executor collections concurrentes + Queue et BlockingQueue des variables atomiques des primitives de synchronisation : sémaphores, mutex, barrières (RV communs de plusieurs threads), échangeur (RV de deux threads et échange de données)... des nouveaux verrous, en écriture et en lecture une précision à la nanoseconde Christophe Garion IN Threads 47/ 49 Références Christophe Garion IN Threads 48/ 49 multithreadedtc : a framework for testing concurrent Java applications. K. Arnold, J. Gosling, and D. Holmes. The Java Programming Language. Java Series. Addison-Wesley, third edition, B. Goetz, J. Bowbeer, T. Peierls, and J. Bloch. Java concurrency in practice. Addison-Wesley, S. Oaks and H. Wong. Java Threads. O Reilly, 2 nd edition, In French, traduction de V. Lamareille. Christophe Garion IN Threads 49/ 49