Discussion :

[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

[�om]

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).

[L4BiN]

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?)

[gifffftane]

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

[Sanguko]

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.

[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

[gifffftane]

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.

[�om]

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!

[L4BiN]

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

[gifffftane]

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

[in]

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

[L4BiN]

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...

[in]

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� ...

[L4BiN]

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

[Sanguko]

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.

[L4BiN]

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?

[Sanguko]

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.

[L4BiN]

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)

[L4BiN]

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

[�om]

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.