IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Concurrence et multi-thread Java Discussion :

[thread] fermer une application


Sujet :

Concurrence et multi-thread Java

  1. #1
    FFF
    FFF est déconnecté
    Membre actif Avatar de FFF
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    342
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 342
    Points : 282
    Points
    282
    Par défaut [thread] fermer une application
    bonsoir,

    J'ai une classe principale possédant une méthode pour la fermeture du programme mutli-thread. La méthode que j'utilise pour fermer l'application est de terminer brusquement un thread pour qu'il passe de l'état "vivant" à l'état "mort" tout en m'assurant qu'aucune donnée ne sera perdue (ce qui m'empêche de faire un System.exit() tout court). La méthode de fermeture de ma classe principale du programme surveille alors l'état de ce thread et termine par un exit :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
            while(monitor.isAlive()) {
                System.out.println("On attend la fermeture du monitor...");
            }
            System.exit(1);
    Ne sachant pas quoi mettre dans la boucle while() j'ai mis un pti texte.

    Cette méthode n'est pas satisfaisante puisqu'elle monopolise le proc (la souris fait des saccades). Que me conseillez vous de faire pour empêcher ceci ?

    Merci.

  2. #2
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2005
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2005
    Messages : 94
    Points : 92
    Points
    92
    Par défaut
    Salut,
    oui y'a des chance que le proc hallucine, imagine si pendant ce temps il doit écrire dans un fichiers quelques dizaines de milliers de lignes ...
    je propose donc de remplacer :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    while(monitor.isAlive()) { 
      System.out.println("On attend la fermeture du monitor..."); 
    } 
    System.exit(1);
    par :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    while(monitor.isAlive()) { 
      try{
        Thread.sleep(200);
      }catch(InterruptedException ie){
        System.out.println("On attend plus la fermeture du monitor..."); 
      }
    }
    étant entendu que par ailleurs il y à une condition genre while(running){}
    (dans run() ) et ailleurs encore une autre if(fini){running = false)} ...
    il y a aussi la synchronisation pour çà, à voir .
    A++

  3. #3
    FFF
    FFF est déconnecté
    Membre actif Avatar de FFF
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    342
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 342
    Points : 282
    Points
    282
    Par défaut
    ok merci, ça me conviens tout à fait !!! Je me rappelais plus que sleep était une méthode statique et que l'on pouvait l'utiliser comme cela ...

    étant entendu que par ailleurs il y a une condition genre while(running){}
    (dans run() ) et ailleurs encore une autre if(fini){running = false)} ...
    of course !!

    il y a aussi la synchronisation pour çà, à voir .
    Je pense que tu fais allusion à une méthode synchronisée possédant un notify() à la fin ? Ceci m'obligerait à faire une boucle infinie me semble-t-il dans ma classe principale pour toute la durée de fonctionnement de l'application pour surveiller les verroux de fermeture... non ? alors qu'ici je le fais seulement à le fermeture...
    je pense qu'il y a plus élégant que ma méthode, mais bon n'ayant pas beaucoup de thread, je trouve cela assez simple et efficace, mais bon je suis ouvert à toutes suggestions...

  4. #4
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Salut,

    Citation Envoyé par jcodeunpeu
    oui y'a des chance que le proc hallucine, imagine si pendant ce temps il doit écrire dans un fichiers quelques dizaines de milliers de lignes ...
    En effet, et même sans afficher de ligne cela reste très lourd car le processus fera un nombre incalculable d'appel à la méthode isAlive()...
    Ce type d'attente s'appelle une attente "active" puisque le processeur reste actif pendant tous le temps de l'attente...


    Il est donc préférable de faire "dormir" le processeur pendant cette attente : c'est ce qu'on appelle l'attente "passive"...
    La solution de jcodeunpeu peut faire l'affaire, en réglant le temps du sleep() selon la durée de ton thread afin de ne pas réveiller le processeur trop souvent...


    Citation Envoyé par jcodeunpeu
    il y a aussi la synchronisation pour çà, à voir .
    Oui et je pense que c'est même plus simple...

    Il suffit de synchronizer la méthode run() sur l'instance du Thread dans lequel elle est lancé, par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    public void run() {
    	synchronized(Thread.currentThread()) {
     
    		// Traitement du thread ici
     
    	}
    }

    Du coups l'attente de la fin du thread se fait de la sorte :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    while (monitor.isAlive()) {
    	synchronized(monitor) {
    		// empty
    	}
    }
    Le bloc synchronized à l'intérieur du while() endormira le thread principal pour ne le reveiller qu'a la fin du bloc synchronized de la méthode run().
    Le while() reste neccessaire pour gérer le petit labs de temps entre le démarrage du thread et l'entrée dans le bloc synchronized, ainsi que la sortie du bloc synchronized et la fin réelle du thread...


    Sinon avec Java 5.0 la nouvelle API de concurrence permet également de faire quelque chose de similaire... Cf ce message : Question d'implémentation: boucle active


    a++

  5. #5
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2005
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2005
    Messages : 94
    Points : 92
    Points
    92
    Par défaut
    Bonsoir adiGuba,
    merci pour ce jour nouveau porté sur le probleme, une pure merveille, trés instructif la synchronisation du thread courant, je n'y pensais pas et c'est trés élégant ... merci encore.
    A++
    ps : si tu peux jeter un p'tit coup d'oeil à mon post si tu as le temps :
    [Process][Localisation ...] merci d'avance.

  6. #6
    FFF
    FFF est déconnecté
    Membre actif Avatar de FFF
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    342
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 342
    Points : 282
    Points
    282
    Par défaut
    Merci pour vos réponses !!

    Citation Envoyé par adiGuba
    Du coups l'attente de la fin du thread se fait de la sorte :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    while (monitor.isAlive()) {
    	synchronized(monitor) {
    		// empty
    	}
    }
    Pour ne pas répéter ce qu'a dit jcodeunpeu je te demanderais simplement un éclaircissement (si possible ?) c'est bien la fin de l'exécution de la méthode synchronized du run() (et non le run() en entier) qui fait que synchronized(monitor) peut être exécuté ?

    Merci pour la méthode !

  7. #7
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2005
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2005
    Messages : 94
    Points : 92
    Points
    92
    Par défaut
    Bonjour FFF,
    ce que je comprend, c'est qu'il est fait de ce Thread (courant) un objet synchronized, tout entier, la méthode run fonctionne de toute façon un peu comme le main d'une classe, tant que toutes les instructions du corps ne sont pas exécutées , il continue.
    le point de synchronisé le thread tout entier, force cet objet(Thread) à notifier( peut être de façon implicite) la fin de sa propre exécution, information qui est attendu de l'autre côté par un autre bloc synchronisé
    ayant pour cible cet objet (les méthodes synchronisées vont de paire, une qui dit quand l'objet est prêt, une qui attend que celui-ci le soi :
    comme adiGuba le dit : un simple if(monitor.isAlive()) ne suffit pas, car ...
    enfin je peut pas paraphraser adiGuba, çà sera moins clair, ce qui peut t'éclairer, c'est qu' un objet l'est toujours 2 fois:
    en notification d'un résultat et en attente de ce résultat.
    et qu'une méthode synchronizée l'est en rapport à une autre, elle peuvent communiquer parcequ'elles sont toutes deux synchronized...
    en bref je dirai que run() n'est pas synchronisée, ne peut pas l'être d'ailleurs, puisque c'est juste un déclencheur, c'est bien l'objet, et non une méthode, qui est synchronized :
    synchronized(Thread.currentThread()){} rend le thread courant synchronisé, ce qui signifie que ailleurs, une instruction
    synchronized(monitor){} stop net l'exécution du code qui suit à cet endroit, et qui est un nouvel appel à isAlive(). Tant que monitor n'a pas reçu le message de la part du premier bloc (ce message est en somme "jesuis arrivé à la fin de moi-même", c'est comme çà; une fois fini, un nouveau passage dans while est possible du coup, qui renvoie maintenant faux ... j'espère que je me suis pas trop emmélé les pinceaux../
    A++

  8. #8
    FFF
    FFF est déconnecté
    Membre actif Avatar de FFF
    Profil pro
    Inscrit en
    Mai 2002
    Messages
    342
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2002
    Messages : 342
    Points : 282
    Points
    282
    Par défaut
    Autre solution :
    utiliser la méthode join(int msec) de la classe Thread permettant d'attendre la mort d'un thread pendant msec millisecondes (0 pour attendre indéfiniment), c'est la solution que j'ai retenue et ça à l'air de bien fonctionner.

  9. #9
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2005
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2005
    Messages : 94
    Points : 92
    Points
    92
    Par défaut
    salut,
    mais cela sous-entend de connaître le délai d'attente avec précision + éventuellement petite marge ... ????

  10. #10
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par jcodeunpeu
    salut,
    mais cela sous-entend de connaître le délai d'attente avec précision + éventuellement petite marge ... ????
    Non justement... join(0) ou join() tout court qui est équivalent) attendra la fin du thread sans délai d'attente...

    a++

  11. #11
    Membre régulier
    Profil pro
    Inscrit en
    Novembre 2005
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2005
    Messages : 94
    Points : 92
    Points
    92
    Par défaut
    oui oui, pour le cas choisit join(0) ....

  12. #12
    Membre habitué
    Profil pro
    Inscrit en
    Novembre 2005
    Messages
    106
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Novembre 2005
    Messages : 106
    Points : 130
    Points
    130
    Par défaut
    dites donc ca devrait être un tuto ca ?
    "Comment synchronizer le thread principal avec un ou plusieurs thread secondaires de manière élégante "

    Merci messieurs pour la lecon.

    PHP / J2EE

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Fermer une application Windows
    Par telecnop dans le forum Langage
    Réponses: 20
    Dernier message: 28/06/2006, 21h15
  2. Fermer une application externe
    Par jean tof dans le forum C++Builder
    Réponses: 2
    Dernier message: 02/05/2006, 16h18
  3. Fermer une application exterieure
    Par P.B dans le forum Windows
    Réponses: 4
    Dernier message: 01/12/2005, 15h17
  4. [VB6]Fermer une application avec VB
    Par Mylou dans le forum VB 6 et antérieur
    Réponses: 3
    Dernier message: 04/04/2003, 21h32
  5. Fermer une application à l'aide de OnIdle
    Par Thierry Rapp dans le forum Composants VCL
    Réponses: 2
    Dernier message: 29/08/2002, 12h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo