problme de multi thread

Bonjour,

Voici mon probleme....

J'ai programmer une application qui fait du multi Threading...
Quand je test cette application en local (ma machine windows ) sous eclipse ou sous monAppli.jar ca marche.
Quand je déploie l'appli sous linux et que je l'execute sous eclipse aucun probleme, mais par contre sous linux le monAppli.jar se lance, et dés que j'execute la partie multi threading ca plante duex thread se mettent en deadlock...
ma question est qu'est ce qui est différents entre tous ces environnement pour que ca cause ce probleme que si on est sous linux et que l'on execute le prog a partir du .jar

merci d'avance

Citation:

---

Envoyé par L4BiN

Bonjour,

Voici mon probleme....

J'ai programmer une application qui fait du multi Threading...
Quand je test cette application en local (ma machine windows ) sous eclipse ou sous monAppli.jar ca marche.
Quand je déploie l'appli sous linux et que je l'execute sous eclipse aucun probleme, mais par contre sous linux le monAppli.jar se lance, et dés que j'execute la partie multi threading ca plante duex thread se mettent en deadlock...
ma question est qu'est ce qui est différents entre tous ces environnement pour que ca cause ce probleme que si on est sous linux et que l'on execute le prog a partir du .jar

merci d'avance

---

C'est que tu as mal géré ton multi-threading, et que sous une certaine exécution il existe un deadlock... Après que telle ou telle exécution ait plus de chance d'arriver sous windows ou sous linux, peu importe.
Il faut revoir la cause de ton problème (montre le code si c pas trop long).

c'est ce que je me suis dit, mais la partie multi threading est a été géré par une autre personne, et jusqu'à maintenant sur tout les pc ou j'ai dut installer des applications utilisant ces threads, il n'y a jamais eu de problemes pourtant c le meme environnement..

Ce probleme n'existait pas il y a deux semaines puis il est apparu comme par magie (et il ve plus partir maintenant)...

J'aurais voulu savoir quelle est la différence entre un programme exécuté à partir des sources (sous eclipse) et un programme executé à partir d'un executable .jar ? (sachant que dans les deux cas l'exécution a lieu sous le meme pc sous le meme linux sauf que dans le cas du .jar ca plante... et pas dans l'autre cas)

de plus comment puis je tester la concurrence des threads.... (y a t-il une technique spécifique hormis le debuggage manuel?)

La seule technique valable pour résoudre un problème de blocage de thread est la réflexion et l'intelligence !... Le debogage manuel ne te servira à rien pour ce genre de problème.

Donc fait marcher tes loupiottes :king:

Il n'y a pas de difference entre l'execution d'un jar directement ou sous eclipse. Par contre, l'environnement, l'ensemble des applications externes qui tournent, a une influence sur le sequencement des threads. C'est pour ca que le probleme peut apparaitre aléatoirement.
Pour corriger, il n'y a pas d'autre solution fiable que d'éliminer la source du deadlock.

est ce que la gestion (le chargement a mon avis pour mon probleme) des threads est différentes sous l'application lancer par eclipse sous linux et sous l'application lancer sous .jar sous le meme linux???

merci d'avance

Cela dépend de la JVM que tu emploies. Si la JVM que tu emploies sous Eclipse et sous Linux est différente, alors il se peut qu'il y ait une différence dans le séquencement des threads.

On ne parle pas - à ma connaissance - de chargement pour les threads. La seule chose qu'on charge en java ce sont les classes, avec le ClassLoader. Et là il se peut très bien qu'un ClassLoader change d'une appli à l'autre, même en gardant la même JVM. Cela peut avoir des conséquences sur les initialisations statiques, sur les locks s'ils sont faits n'importe comment, mais pas au niveau du séquencement des threads lui même.

Citation:

---

Envoyé par L4BiN

est ce que la gestion (le chargement a mon avis pour mon probleme) des threads est différentes sous l'application lancer par eclipse sous linux et sous l'application lancer sous .jar sous le meme linux???

merci d'avance

---

De toute façon quand tu programmes, tu ne dois surtout pas te préoccuper de l'implantation de la jvm (et donc de l'ordonnancement des threads), ton système ne doit donc pas en dépendre!

je voudrai bien qd meme pouvoir vérifier si la JVM ne pe pas etre la cause de mes soucis....

Ou est ce que je peux trouver la description de la JVM sous eclipse,
sous linux et sous windows ?

merci

Il est rare que je donne à quelqu'un un lien en étant persuadé qu'il perd son temps ! Cependant : http://java.sun.com. Comme tu ne nous dis même pas quelle sont les versions de ces outils et JVM, tu pourras choisir toi même. Peut être, un peu plus spécifique, mais probablement adapté : The Java Virtual Machine Specification.

Après, pense à regarder le logiciel :D

Bon je dis ça un peu au pif mais j'ai récemment été confronté à des erreurs dans une appli multithread qui marchait très bien sous Windows et pas aussi bien sous Solaris ...

j'ai résolu en changeant la politique de gestion des threads au lancement de java : -XX:+UseLWPSynchronization -XX:+UseParallelGC

tu peux aussi jouer sur la version de libthread.so qui est utilisé (en changeant la variable LD_LIBRARY_PATH).

Enfin bon je doute que ça résolve ton pb mais je te donne le lien qui m'a rendu service à l'époque. c'est un lien sun évidemment ;)

ce que je ne comprend pas si ca ne peux pas etre une histoire de JVM, qu'est ce que ca peu etre.
Comment est t'il possible que il y est des deadlock quand l'appli est lancer en .jar et pas sous eclipse alors que l'on est sur le meme pc avec le meme linux , (vu qu'apres verification la jre et jdk utilisées sont les memes dans les deux cas).
Deux plus la gestion de la synchronization a été fait il ya longtemps, par d'autre gens que moi, et jusque la partout ou ca a été déployé ca a marché, et là par magie ca ne marche plus... (donc ca ne doit pas etre une histoire de synchro)... mais peut etre d'initialisation des threads???

Je vous aurai bien poster du code, mais il y en a tellement que je ne sais pas quoi vous envoyer...

ben essaie d'utiliser des options de la JVM ou de changer la librairie libthread.so comme je te le propose.

La politique de gestion des threads dépend de l'OS aussi ... (enfin un serveur solaris est peut être un cas particulier ?), ça vaut quand même le coup d'essayer non, c'est une modif mineure et au moins tu seras tout de suite fixé ...

ou est ce que je trouve ce fichier libthread.so ?

Ca n'est pas parce que ca a marché avant qu'il n'y avait pas le bug. Tu as simplement la chance (ou la malchance) de le découvrir en premier.

En général, les threads java sont mappés sur des threads natifs. L'ordonnancement des threads est géré par le système. Du coup, il suffit que tu aies une application (autre que java) qui tourne, pour que l'ordonnancement des threads ne soit plus le meme et que le probleme de deadlock apparaisse.

Le mieux, c'est de vérifier si oui ou non il y a bien un problème potentiel de synchronisation, en regardant le code. Je ne me souviens plus, mais il me semble que lorsque tu a un probleme de deadlock, tu devrais avoir les threads responsables, ainsi que les piles d'appel de chaque thread. Ca devrait te permettre de regarder dans le code si oui ou non, ca peut effectivement arriver.

mais pourquoi alors sur le meme pc le .jar plante quasiment à chaque coup,
et sous Eclipse à partir du source directement ca marche à tous les coups?

Peut être que la différence vient du fait que sous eclipse, tu charges les .class directement, et donc tu n'as pas à faire l'étape de décompression du .jar.

Mais peu importe. Imaginons que tu trouves la raison pour laquelle le comportement est différent. Il reste quand même une tres forte chance pour qu'il y ait un bug dans la synchronisation. Il est a mon avis necessaire que tu te penches sur le code.

je crois qu'il me faut effectivement me résoudre à faire cela, et quand on vois la tete du code ca fait pas plaisir....
mais de toutes les manières je crois que je ne vais pas pouvoir faire grand chose car c du code protégé par un copyright...

mais ce qui me gène qd meme c que des appli, utilisant exactement le meme multi threading, installé dans les meme condition sur d'autre pcpossèdant le meme systeme d'exploitation, ne plante jamais,

alors je ne peux pas m'empéché de penser qu'il peut y avoir une autre raison que une mauvaise synchro... sauf que je ne m'y connai pas assez sur ce sujet pour savoir quoi....
mais bon essayons de comprendre cette synchronization qd meme... (ca fait peur oulala)

le multi threading utilisé dans mon application vien du code du logiciel ptolemy http://ptolemy.eecs.berkeley.edu/

et j'ai du mal a croire qu'un logiciel assez répendue comme celui si est un probleme de synchronizations

Citation:

---

Envoyé par L4BiN

ce que je ne comprend pas si ca ne peux pas etre une histoire de JVM, qu'est ce que ca peu etre.

---

Ceux qui ont géré la synchro ont dû faire des hypothèses (fausses) de fonctionnement des threads.
Et comme tout le monde le sait, à partir d'hypothèses fausses, on peut obtenir n'importe quoi...
Donc dans certains cas, ça peut marcher, dans d'autres non.

Bon je pense que je vais perdre bcp trop de temps a essayer de comprendre le probleme de manière trop précise.
Maintenant il me parrait évident que c'est un probleme de synchro et que il faut revoir la gestion de la concurrence des threads.

Malheureusement pour moi je ne suis pas très fort de ce coté là,
Le programme est tres gros, possède bcp de class et de fichier... et c'est un peu un plat de nouille.... alors si quelqun connai une méthode pour faire ce genre d'analyse (ou connai un site expliquant comment bien faire) je l'en remercie d'avance de me le faire savoir.... merci... d'avance ;)

Moi je peux le faire mais c'est payant ! :D

... et sur ce genre de truc cela peut être long.

Les méthodes qui me semblent les meilleures :

1. Si l'on peut attendre, profiter des modifs du programme pour faire du refactoring et l'améliorer petit à petit. Un jour le bug sera résolu (ou au moins expliqué).
   
2. Si l'on ne peut pas attendre... alors il faut tout refaire, et donc attendre : il n'y a pas de miracle. Je pense que c'est la méthode la plus rapide et la meilleure pour avoir un résultat fiable ; toutefois, elle est conditionnée à la compréhension de ce qui a foiré au cours du premier projet (explication qui ne doit pas être : c'est de la faute de...), car sinon les mêmes causes produiront les mêmes effets.

Le plus raisonable : tenter le 1 pendant 3 mois (par exemple), et si ça ne marche pas, passer au 2.

le probleme a été peut etre détecté, ce serai un appel a ClassLoader qui entrainerai l'apparition de deadLock.
On a prévue de changer l'endroi de l'appel à cette class dans le code.
Je vais aller tester dan le laboratoire ou doit est déployé le prog...
espérons que ce soit ca... ca m'éviterai le travail décrit par notre ami(e) giffftane...
souhaité moi bonne chance... :roll: