Discussion :

[qdesmedt]

Bonjour,

Je travaille en Java sur une application de manipulation d'objet 3D avec un appareil Leapmotion (www.leapmotion.com).

Concernant la manipulation 3D j'utilise VTK, une librarie OpenSource basée sur OPENGL (bien sur).

Bref, ma question est plutôt simple:
Dans un Thread vaut-il mieux:

• Faire une boucle while(true) et un sleep de quelques millisecondes pour permettre aux autres taches de travailler ?
• Utiliser la classe Timer répétitif.

J'aimerais une réponse basée sur les performances afin que mon Thread qui met à jour l'affichage 3D ne soit pas dérangé par le Thread qui récupère les informations du Leapmotion.

Merci beaucoup.

[tchize_]

ca dépend. Il vaut toujours mieux utiliser des wait/notify, des semaphore ou des trucs du genre que de faire des sleeps.

Le timer, ça dépend de quel timer tu parle

[JoeChip]

Pourquoi "while (true)" ? Je n'arrive pas à comprendre pourquoi tout le monde veut faire ça... Il y a pourtant forcément une condition de sortie de la boucle...? Une survivance du "goto" ?

[thelvin]

Pourquoi "while (true)" ? Je n'arrive pas à comprendre pourquoi tout le monde veut faire ça... Il y a pourtant forcément une condition de sortie de la boucle...? Une survivance du "goto" ?

- Des fois la condition de sortie ne peut être qu'une exception, d'autres fois c'est plus clair avec des return.

- Il n'existe, a priori, aucun rapport entre goto et boucles (fussent-elles infinies.)

[JoeChip]

Il n'existe, a priori, aucun rapport entre goto et boucles

Jamais fait de BASIC ? Mais bon, même sans ça, un "while true" équivaut à un " à la fin de la boucle, goto l'endroit du while". Et on peut toujours sortir de la boucle sur une condition, return ou pas, break ou pas, exception ou pas... Et tu ne répond donc pas à ma question... Pour moi, sortir d'un thread à l'arrache est forcément une drôle d'idée, qui devrait être beaucoup plus rare que sortir clean. Donc je ne comprend pas pourquoi le "while true" semble aussi systématique dans les threads. Donc j'aimerais qu'on m'explique, puisque quelque chose semble m'échapper...?

[thelvin]

Ah, si on parle du fait qu'il tend à apparaître systématiquement, c'est dû au fait que les gens ne se rendent pas compte que le programme est censé s'arrêter un jour, certes.
Moi je parlais que des cas, plus rares en effet, où sortir autrement se justifie.

[qdesmedt]

Je précise ma question.

J'ai donc 2 Threads. Un qui récupère les coordonnées des doigts tout au long de mon application et un qui s'occupe de l'affichage et des modifications des objets 3D.

Pourquoi utiliser While(true) ? Parce que ces 2 threads sont lancés et ne doivent jamais être stoppé durant le déroulement du programme.

Maintenant, le thread qui s'occupe de la 3D a un délai de répétition plus faible que l'autre.

Exemple:

Thread 1 : 3D

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
While(true){
    updateObject3D();
    render();
    Thread.sleep(100);
}

Thread 2 : récupération des données du leapmotion et envoie d'un message si besoin pour la modification de l'affiche au Thread 1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
While(true){
    addEventForThreadOne();
    Thread.sleep(30);
}

Jusqu'à maintenant j'utilise la fonction sleep(). Vous me dites qu'en utilisant wait/notify/notifyAll, je peux obtenir une solution plus performante ?
Si le while(true) n'est pas une technique a utiliser, que faire ?

Merci beaucoup de vos réponses.

[EDIT] Pour le passage de message entre le Thread, j'utilise une FIFO synchronized.

[Lucio_]

Jusqu'à maintenant j'utilise la fonction sleep(). Vous me dites qu'en utilisant wait/notify/notifyAll, je peux obtenir une solution plus performante ?

Avec un sleep, il y a trois cas de figure:

1. Soit le temps est bon
2. Soit le temps est trop court, du coup l'appli perd du temps
3. Soit il est trop long et l'objectif n'est pas rempli

L’avantage du wait/notify/notifyAll, c'est que quand un travail est terminé, l'autre Thread est averti. Donc probablement le temps perdu (surtout si le temps est trop court) sera moins important, et donc la performance meilleur.

[JoeChip]

Si le while(true) n'est pas une technique a utiliser, que faire ?

En fait il y a forcément une condition de sortie à la boucle, à moins que ça ne concerne un calcul "infini" type gestion de central téléphonique.

Dans ton cas, le "while true" est peut-être parfait, mais à mon avis on a bien plus de souplesse et donc de possibilités de réutilisation en prévoyant une variable de contrôle, ce qui permet de stopper le thread de l'extérieur, et d'en sortir proprement, et donc par exemple de faire des traitements après la fin de la boucle. Donc ça devient un truc genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    running = true; // éventuellement à l'initialisation de l'instance etc
    [ ... ]
    while (running) {
        [boucle]
    }
    [instructions de fermeture]

En prévoyant dans la classe qui implémente Runnable un truc genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    public void stop(){
        running = false;
    }

Ce qui permet de contrôler bien mieux... On peut aussi passer par exemple par un entier ("while (running == 0)"), afin de distinguer les différentes conditions de sortie de la boucle et les traiter localement.

[qdesmedt]

Merci JoeChip, je comprends bien ce que tu veux dire.

L’avantage du wait/notify/notifyAll, c'est que quand un travail est terminé, l'autre Thread est averti. Donc probablement le temps perdu (surtout si le temps est trop court) sera moins important, et donc la performance meilleur.

Lucio_, je comprends ce que tu dis mais avec la technique wait/notify, mes 2 threads vont se dérouler l'un après l'autre. Si, dans mon cas, un des Threads a un temps d'attente 2 fois moins long que le deuxième. Il va pouvoir se faire 2 fois plus que le Thread 2.

Exemple:
Thread A,B;
A => sleep(30)
B => sleep(80)

Déroulement du programme:
B - A - A - B - A - A - B

car pendant que le programme B "dors", le thread A a le temps de faire 2 fois le tour de se sa boucle.

Maintenant avec wait/notify:
A - B - A - B - A

Ai-je raison ?

Ps: Je suis un boulet, je ne vois pas le bouton pour mettre mon POST en résolu :s ?
[EDIT] JE suis un boulet, j'ai trouvé le bouton...

[JoeChip]

Le problème, je pense, c'est que tes waits ne sont pas forcément synchrones : du temps peut passer en plus, notamment dans d'autres threads... Il me semble que le wait stipule un temps minimal d'attente...?

[Lucio_]

Lucio_, je comprends ce que tu dis mais avec la technique wait/notify, mes 2 threads vont se dérouler l'un après l'autre. Si, dans mon cas, un des Threads a un temps d'attente 2 fois moins long que le deuxième. Il va pouvoir se faire 2 fois plus que le Thread 2.

Exemple:
Thread A,B;
A => sleep(30)
B => sleep(80)

Déroulement du programme:
B - A - A - B - A - A - B

car pendant que le programme B "dors", le thread A a le temps de faire 2 fois le tour de se sa boucle.

Maintenant avec wait/notify:
A - B - A - B - A

Ai-je raison ?

C'est en partie vrai car il est possible de ne notifier B qu'une fois sur deux.
Et le risque que je vois, c'est de se retrouver avec A et B qui dorment en même temps. Ce qui est du temps de calcul de perdue.

Par contre, si A est trop long, est ce qu'il est nécessaire de lancer B? l'affichage temps réel, c'est pas mon fort, donc je demande

[JoeChip]

En fait, si tu veux que ça fasse B A A B A A B A A B etc, il n'est pas logique de faire des threads séparés si ? si tu veux que les trucs soient synchronisés (= avec une séquence chronologique déterminée), ils doivent être dans le même thread, ou se synchroniser par signaux.

Tu ne peux pas supposer par exemple que puisque A fait un wait de 30 et B un wait de 80, ça fera B A A B A A B A A (ce qui est d'ailleurs faux à la base, puisqu'en fait même avec ce raisonnement, ce sera plutôt B A A A B A A A B, avec parfois B A A B).

Par ailleurs, si tu ne regarde pas l'heure depuis le thread, tu ne peux pas savoir combien de temps est passé depuis le dernier wait. Par exemple, si le CPU est surchargé, il est possible que le thread ne soit que (très) rarement en cours de fonctionnement... Et que ton wait ne soit appelé que toutes les secondes...