Stopper un thread dans son travail pour lui demander de recommencer à zero

Salut salut !

Alors voilà, je suis en fasse d'une difficulté pas trop pratique.
C'est la première fois que je fais appelle à ce forum et je n'ai pas trouvé de section plus adaptée alors si je suis au mauvais endroit veillez m'en excuse.
Sachez que la situation est grave ! Dit il en prenant un air faussement sérieux. Cela fait 24 heures que j'ai posté mon soucis sur un autre site et pas une seul réponse...
Et je me rends compte que les gens vraiment pointus en java sont plutôt ici... Du coup je viens ici pour trouver quelqu'un capable de répondre à mon soucis !

Mon jeu comporte quelques thread afin de gérer ces différents éléments. L'un deux me pose des soucis.... C'est celui du pathfinder !

Besoin du pathfinder à couvrir :

-trouver un chemin dans un thread différent afin d'animer le personnage.

-pouvoir lancer un nouveau déplacement et donc interrompre le précédent a la fin de sont animation (celle du déplacement d'une case à l'autre)

J'ai tenté plusieurs solutions pour ça mais aucunes n'as réellement marché à 100%.

Actuellement je lance le thread unique du pathfinder (au lieux d'en créer un nouveau à chaque fois et le fermer juste après) qui à une méthode run() avec une boucle infinie qui lance un replacement des que certaines variables le permettent.

Il faut savoir qu'a chaque boucle de recherche de la prochaine case, lorsqu'il y à déplacement je fais appelle à un sleep pour les animations.

Ca marche très bien, je clique, mon personnage bouge, arrive à destination. Je clique à nouveau, ça remarche. Le soucis est lorsque je veux spammer le déplacement (déjà pour interrompre un trajet précédent) les variables ne se mettent pas correctement à jour et surtout le thread passe en BLOCKED....

Pourtant les méthodes sont synchronisée et les variables utiles sont en volatile...

Comment feriez vous pour laisser un thread ouvert dans un coin (ou bien en ouvrir un à chaque fois, mon jeu est bien optimisé, je m'en fiche si c'est juste pour le pathfinder) capable d'être appelé à n'importe quel moment, même s'il est en pleins pour qu'il puisse se quitter des la fin de sa boucle afin de recommencer ces boucles des le début avec de nouvelles données ?

Merci d'avance, en espérant que quelqu'un sauras m'éclairer un peut ! :)

ben si tu veux arrêter le calcul, un boolean arreteToi en volatile que les autres threads mettent à true quand ils veulent arrêter ton thread courant.
Si tu veux retourner à ton run facilement, une Exception que tu fais remonter.

Pour ton thread en blocked, quand ça arrive, il faut analyser quel verrou il attends pour savoir d'ou viens le deadlock

Tout d'abord merci d'avoir répondus.

Je ne connais pas trop les Locks. En fait j'ai assez lu sur sa théorie pour savoir ce que c'est et comment ça fonctionne mais jamais tâté en pratique.

Même en volatile j'ai des soucis. En revanche quand je retire le sleep ça marche bien mieux mais bon...

Je vais me replonger dans ce code la (car entre temps je me suis mis à quelque chose de méga éloigné de ça du coup je ne l'ai plus en tête) et je ferais un up avec le code que j'utilise et le soucis posé.

Citation:

---

Envoyé par -WalakaZ-

Je ne connais pas trop les Locks. En fait j'ai assez lu sur sa théorie pour savoir ce que c'est et comment ça fonctionne mais jamais tâté en pratique.

---

Dès que tu fait des méthodes synchronized, tu crée des verrou, sur l'instance contenant la méthode. Si ton thread 1 ne répond plus et est BLOCKED, c'est qu'il attends des verous d'autres threads. Si ces autres thread attendent des verrou actuellement possédés par thread 1, tu a un deadlock.

Huuuunnnn, d'accord !
En fait je n'ai pas de deadblock, le jeu block même pas 250 millisecondes, mais étant donné que chaque nouvelle image de l'animation sors toute les 75 millisecondes et qu'il n'y en à que quatre ça me fais une sacré saccade.
En fait au fur et à mesure de mes essais toute les fonctions annexes sont passée en synchronized et c'est donc un tord. Certainement tout ça qui doit fair bugger mon bazars étant donné que je n'ai besoin que d'une boolean en volatile.

Je teste dans la journée, je ferais un message de compte rendus de mon aventure !
:Saute avec sa bite et sont couteau dans sont CPU: :aie:

Bon, alors.....
Finalement je n'ai pas essayé cette solution, j'ai repris mon code de départ, viré toute les synchronisations et volatiles que j'avais mis.
En fait au début de ma fonction j'avais un while(!variable); qui attendais que le thread ai terminé pour se lancer. J'ai simplement rajouté dedans un .sleep(1) pour le faire patienter et voilà.

C'est suite à une découverte que j'ai fais ce matin x) je ne sais pas pourquoi mais quand j'ai commencé le java quelqu'un ma mis en tête qu'il fallait à tout pris éviter les sleep qui faisaient tout ramer...
En réalité cette personne était totalement dans l'erreur car au lieux de monter méga haut le CPU ne bouge plus avec le sleep ! :)

Cette erreur de merde m'auras quand même vachement appris, je te remercie pour la réponse qui m'a aidé pour d'autres choses.
Sujet résolut !

Citation:

---

Envoyé par -WalakaZ-

quand j'ai commencé le java quelqu'un ma mis en tête qu'il fallait à tout pris éviter les sleep qui faisaient tout ramer...
En réalité cette personne était totalement dans l'erreur car au lieux de monter méga haut le CPU ne bouge plus avec le sleep ! :)

---

Comme dans tout language (et comme son nom l'indique), sleep ne consomme pas de CPU. Par contre, dans un client lourd type awt/swing (que je suppose etre ton cas), il est vrai qu'il faut eviter les sleep dans le thread EDT (le thread qui met à jour l'IHM). C'est pas pour une raison de CPU mais ca donne l'impression que l'appli rame.

Disons qu'il vaut mieux éviter les sleep pour faire des boucle d'attente. Ce qu'il faut éviter c'est ce pattern:

Code:

---

1 2 3 4 5 6

while(true){ if (quelqueChoseAFaire){ lefaire(); } sleep(100); // on re-testera dans un dixième de seconde }

---

Avec quelqueChoseAFaire dépendant d'un autre thread / du user.

Car plus le sleep est grand, plus le délai de réaction sera grand, plus le sleep est petit, plus te fera de boucle inutile car il n'y aura rien à faire. Il veux mieux avoir ce pattern:

Code:

---

1 2 3 4

while(true){ attendreQuelqueChoseAFaire(); lefaire(); }

---

avec le attendreQuelqueChoseAFaire qui attends un notification via un semaphore. Dans ce cas: le thread ne se réveille pas pour rien, et il se réveille presque instantanément.

Il s'agit d'une attende d'en moyenne 30 millisecondes la. Pour ça que c'est si bas. (je ne fais jamais de sleep dans les threads principaux)
et il faut que ça soit dispo le plus vite possible pour continuer le déplacement sans saccades ou autres latences visuelles.