Les threads.... Résolu

Question

Salut tout le monde,

j'ai une petite question concernant les threads....
Voila le contexte, j'ai un objet herite d'un datagrid qui permet de charger des donn&#233;es en parametrant 2 trois proprietes directement dans le mode design et en lancant une fonction...

en fait j'ai 2 select possible, un qui sera execute normalement (ie dans le thread principale de l'appli) qui permettra d'afficher un certain nombre de ligne tout de suite, le 2eme select est la lui pour remplir le reste du datagrid je m'explique, j'ai une table de 200 000 lignes, si je charge tout a partir du thread de l'appli ca rame, donc mon premier select charge les 1000 premieres lignes et le 2eme select (qui sera lancer dans un thread diff&#233;rent) charge les 199 000 autres lignes comme ca l'utilisateur a l'impression que c charger alors que ca continu a bosser derriere :o)

seulement voila....
g donc une m&#233;thode qui me lance le premier select affiche le resultat, et lance dans un 2eme thread l'autre select...
a un moment g vu qu'il fallait faire un thread.Abort() ou un truc du style...
pour arreter le thread...
a priori ca le fait ...mais si je ferme la fenetre et que je relance...pouf ca plante...erreur de memoire, jamais la meme erreur...la fete...

par contre si je bloque le 2eme select he ben pas de pb (car a mon avis pas de thread en +)
je lance la fenetre autant de fois que je veux...

une idee...

l'interet de faire un thread.sleep(..)
thread.join()??????

Help....


Arthenius

 "Il n'y a pas de mauvais d&#233;veloppeurs,... 
      mais uniquement de mauvais utilisateurs..."

Arthenius · Accepted Answer

ARGHhhhhhhhhhhhhhhhh

c'etait ca :o)))

desole pour le derangement et merci de votre aide cammarade...

Donc pour eviter les PBs avec les threads : 

INSTALLER AU MOINS LE framework 1.1 SP1 !!!!


Arthenius

 "Il n'y a pas de mauvais d&#233;veloppeurs,... 
      mais uniquement de mauvais utilisateurs..."

ivanoff1 · Answer

A mon avis, tu dois faire un thread.join. 
Ton deuxi&#232;me thread va alors attendre que le premeir &#224; charger les 1000 premi&#232;res lignes, non ?


L'ours a programme du miel!!

Arthenius · Answer

heuuu...
en fait le premier select je le fais pas dans un thread a part (enfin celui de l'appli mais rien de plus)

par contre le "gros" select est fait dans un thread a part pour pas bloquer l'appli...
donc d'apres toi je lance mon thread...et apres je fais un join...

a ce moment je sais que le thread est fini....
mais y a qd meme kkchose que je comprend pas...si je fais un thread.abort() je suis censer terminer mon thread, alors pkoi ca pose probleme qd je ferme et relance la forme ???
?.?????????????????


Arthenius

 "Il n'y a pas de mauvais d&#233;veloppeurs,... 
      mais uniquement de mauvais utilisateurs..."

MorpionMx · Answer

Ca plante seulement quand le second Thread n'est pas termin&#233; ? (les 190000 lignes pas remplies), ou meme quand il a fini ?



Le t.Join() sert a attendre que le thread  t se termine il me semble.

Donc si tu fais un t.Join() A partir du Thread principal, ca va te bloquer ton application je pense :/



Si tu fais, a la fermeture de la fenetre, qqchose comme



(if t != null  && t.isAlive)

{

    t.Abort();

    t = null ;

}



Ca fait quoi quand tu reouvres la fenetre ?



Ah oui, aussi, il faut absolument reinitialiser ton Thread a la reouverture de la fenetre. (Recreer l'instance de t)



Dis nous ce que ca donne, et on va continuer a chercher apres.



(au fait, tu as un exemple d'erreurs que ca provoque ?)



Mx

ivanoff1 · Answer

D&#233;sol&#233; jme suis tromp&#233;!

En fait tu vas bloquer ton deuxi&#232;me thread tant que le premier n'a pas fini son chargement. 
La m&#233;thode "abort" permet d'arr&#234;ter compl&#232;tement le thread ( et de le d&#233;truire apr&#232;s => GC)

Tu peux soit utiliser l'&#233;v&#233;nement "Mutex" ou alors utiliser le mot cl&#233; "lock"

Genre : 
lock (valeur)
{
   // traitement
}

Dans le lancement de ton programme, tu dois utliser le "join", il permet d'attendre qu'un autre Thread ait fini son ex&#233;cution avant de commencer le sien.

Apr&#232;s dans ta classe, il faut utiliser faire :

lock(this)
{
   try
   {
         Monitor.Wait (this); // attendre le Monitor.Pulse d'un autre thread
   }
}


L'ours a programme du miel!!

Arthenius · Answer

bon je vais tester tout ca...
et je vous tiens au cournat...

Mx : mon thread est defini dans ma fenetre il sera donc reinitialiser d'office...
j'avais essayer sur le closing de faire un abort

mais meme punition 

les erreur c des fois des memoryoverflow  et des trucs du genre...

ivanof : rien compris :o((( a ca ???
lock(this)
{
   try
   {
         Monitor.Wait (this); // attendre le Monitor.Pulse d'un autre thread
   }
}

et le mutex kesako ???


Arthenius

 "Il n'y a pas de mauvais d&#233;veloppeurs,... 
      mais uniquement de mauvais utilisateurs..."

MorpionMx · Answer

Il me semblait que la classe Monitor servait a g&#233;rer les acc&#233;s
concurrents ? Ca n'a pas l'air d'etre le cas ici, si ? Les 2 threads
acc&#233;dent a des ressources diff&#233;rentes.

La seule chose qu'on en commun les 2 threads, ce se le datagrid pour le
remplissage final. Et Arthenius dit qu'il lance le 2eme thread une fois
que le premier est fini. Donc ils n'essaient pas de remplir le datagrid
en meme temps, a priori le probleme ne vient pas de la.

Arthenius · Answer

correct Mx...
je n'accede pas au datagrid en simultane mais je le rempli en 2 fois...

bon par contre je viens de faire le test sur une autre machine avec le meme prog et ca marche......

a priori pas le meme framework 1.1 et 1.1 sp1 suir celle qui marche...je regarde si c ca...
et la j'aurai les boules.....


Arthenius

 "Il n'y a pas de mauvais d&#233;veloppeurs,... 
      mais uniquement de mauvais utilisateurs..."

MorpionMx · Answer

Au moins ce serait r&#233;solu si c'&#233;tait ca ! :)

cs_coq · Answer

D&#233;j&#224; le fait d'acc&#233;der &#224; un contr&#244;le depuis un autre thread que celui qui l'a cr&#233;e n'est pas trop conseill&#233;.
Pour ce qui est de l'acc&#232;s concurrent : si l'utilisateur fait scroller le contr&#244;le (par exemple) alors que tu es encore en train d'y ajouter tes items, il y a des risques l&#224; :-)

Cocoricoooooooo !!!!
coq
MVP Visual C#

Les threads....

10 réponses

Votre réponse

Discussions similaires