Discussion :

[Ivan76]

Bonjour,

Je travaille actuellement sur une application très gourmande en calcul, en fait il s'agit d'algorithme génétiques.
Une première étape a été de vouloir suivre graphiquement à l'aide de zedGraph la façon dont évoluait ma population. J'ai donc lancé la partie de mon code gérant l'algo génétique dans un nouveau thread, et je récupère périodiquement des données concernant l'état de l'algo via un callBack.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
// Callback
public delegate void PointsDessin(int numGeneration, int Fitnessmax, int Fitnessmoy, int Distinct);
 
public void dessine(int numGeneration, int Fitnessmax, int Fitnessmoy, int Distinct)
{
zgc.GraphPane.CurveList["Fitnessmax"].AddPoint(numGeneration, champion * multiplicateurY);
zgc.GraphPane.CurveList["Fitnessmoy"].AddPoint(numGeneration, moyen * multiplicateurY);
zgc.GraphPane.CurveList["Distinct"].AddPoint(numGeneration, distinct);
 
refreshCourbes();
}

Ca ça marche bien, je construit dynamiquement mes courbes et je les affiche, sans freeze de mon WinForm. Pour info, j'ai en abscisse le nombre de générations, et en ordonnée 3 valeurs (Fitness la plus haute, Fitness moyenne de la population, nombre "d'individus" différents.)

Maintenant, je voudrais pouvoir lancer plusieurs Threads gérant chacun une instance de mon algo, et moyenner leurs résultats.
J'avais pensé à cette solution :
- créer, par exemple pour la Fitnessmax, un

Code :

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

1
2
3
4
 
int nombreDeThreads = 2;
int[][] Fitnessmax = new int [nombreDeThreads][];
// suivie évidemment d'une boucle pour fixer la taille de chaque élément.

pour chaque courbe.

- Lors de la création du Thread, donner un numéro unique au thread via sa propriété name, et lors de l'appel du callback y ajouter ce numéro de thread,
- Du coup j'aurais pu faire ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public delegate void PointsDessin(int ThreadId, int numGeneration, int Fitnessmax, int Fitnessmoy, int Distinct);
 
public void dessine(int ThreadId, int numGeneration, int Fitnessmax, int Fitnessmoy, int Distinct)
{
Fitnessmax[ThreadId][numGeneration] = Fitnessmax;
// même chose pour Fitnessmoy et Distinct avec leurs tableaux de tableaux respectifs....
// puis mettre à jour mes courbes avec un timer par exemple
 
}

La question que je me pose, c'est que pour moi en théorie je ne devrais pas avoir de problèmes de concurrence entre threads dans ma fonction dessine, car effectivement ils peuvent aller en exécuter le code en même temps, mais puisque qu'ils écriront chacun dans leur Fitnessmax[] identifié par ThreadId on n'aura pas de problème de recouvrement de données.
Seulement ce que je vois un peu partout c'est qu'il vaudrait mieux locker mon tableau de tableau Fitnessmax[][] chaque fois que j'écris dedans. Cela m'ennuie pour des raisons de performance.

Auriez-vous un avis éclairé sur la question?

Si je ne suis pas très clair, n'hésitez pas à me demander des précisions ; les extraits de code que j'ai mis (et allégés) sont peut-être un peu justes.

Ivan.

[Pol63]

la lecture d'une meme variable sur plusieurs threads ne posent pas de problème

ce qui pose problème c'est pas exemple la modification d'une collection (add, remove ...) pendant qu'il y en a un qui parcours la collection
ou encore l'écriture d'une variable par rapport à sa valeur, si plusieurs thread font i = i + 1 ca sera fossé de temps en temps

donc si tes threads ne modifie qu'un element du tableau chacun, je ne pense pas qu'il y aura des soucis

enfin le mieux c'est de tester avec plein de threads, tu verras vite si ca coince !


NB :
pour du thread safe, il y a syncklock en vb.net (lock tout court en c# je crois) (tout le monde attend tant c'est pas déverrouillé
mais aussi les readerwriterlock (et le nouveau de 2008 préfixé de slim), ces locks permettent de ne pas bloquer dans certains et de bloquer dans d'autres, les verrous dit "read" sont non bloquant, les verrous dit "write" sont bloquants, le write bloque les reads et les autres write et ne rentre que lorsque tout le monde a déverrouillé

[Ivan76]

Ok, merci pour ta réponse, de toute façon comme tu dis le mieux c'est de tester.
Fallait seulement que je rentre à la maison pour ça, au boulot je suis en punition depuis un an à faire du pl/sql...

Je tâcherai de revenir poster sur le résultat de mes tests.

[Ivan76]

Ca ma l'air de bien fonctionner finalement.

J'ai effectivement plusieurs threads qui écrivent dans le même Dictionary<int, List<int>>, où la clé du dictionnaire est un identifiant unique et le List<int> est ma liste de points, le tout sans problèmes.

Par contre j'ai changé de stratégie niveau affichage : au lieu d'appeler mes threads depuis mon Form et d'y mettre un timer pour actualiser mes courbes jusqu'au plus petit numéro de génération atteint par le thread le moins avancé, j'ai créé une classe chargé de lancer les threads et de collecter les données qu'ils remontent, et qui signale via un évènement personnalisé à mon Form qu'il y a de nouveaux points à afficher.

J'ai mis un peu de temps à monter mon truc à cause d'un problème assez vicieux : j'utilise un peu partout dans mon projet une classe statique contenant un Random....
Or la classe Random n'est pas thread-safe, et je ne faisais pas de lock quand je faisais un Random.Next.
J'obtenais des résultats complètements déconnants... dur dur de trouver la cause car quand on veut débugguer sous VS2008 une méthode appelée par plusieurs threads, le curseur de débogage saute allègrement d'une ligne à l'autre, en avant comme en arrière dans le désordre le plus total

Bref, plutôt que de faire un lock chaque fois que je fais un Random.Next sur ma classe statique, j'en ai mis privé dans la classe du thread.

[Pol63]

pour le debuggage multithread il parrait qu'il y a un moyen de choisir le thread qu'on veut débugger et de pas voir les autres, peut etre dans la fenetre d'affichage des threads ...