Thread et passage de parametre

Version imprimable

28/11/2011, 15h39
olibara

Thread et passage de parametre

Bonjour

Je suis un peu novice en matiere de MultiThread :oops:

La plupart des exemples que je trouve se contentent de montrer une application simplissime pour une methode void sans parametres affichant un bete hello world

Dans le cas qui me preoccupe je voudrais executer une methode methode devant me retourner une liste de string et qui demande plusieurs parametre Cette methode effectue un download qui cree plusieurs fichiers et doit evidemment me prevenir quand elle a fini !

Avez-vous un lien ou un tutoriel me permettant de mieux appréhender la maniere d'abborder le sujet !

Merci de votre aide
28/11/2011, 15h43
BenoitM

http://glarde.developpez.com/dotnet/bgworker/cs/#LIII.2

Si tu es en 4.0, le plus simple est d'utiliser l'API Task :
Code:

1 2 Task.StartNew(x => LaMethodeQuiRenvoieUneListe()) .ContinueWith(t => FaireQuelqueChoseAvecLaListe(t.Result));

28/11/2011, 16h24
olibara

Merci TomLev

Non, je suis encore en 3.5

Merci BenoitM
C'est vrai j'avais pensé au BackroundWorker

Mais ca me semblait plus "bricolage" et sans etre certain que ca réponde au besoin
J'avais donc a priori négligé cette possibilité

Je vais y jeter un oeil.

D'autres avis ?

Voici un petit exemple :

Citation:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
    using System;
    using System.Threading;
    // En .Net 1.x
    namespace Threads
    {
    public class MonThread
    {
    int i = 0;
    public MonThread(int i)
    {
    this.i = i;
    }
    public void ThreadFonction()
    {
    for(; i<=30; i++)
    {
    Console.WriteLine(i.ToString());
    Thread.Sleep(300);
    }
    }
    }
    public class Exemple
    {
    public static void Main()
    {
    MonThread mt1 = new MonThread(5);
    Thread t1 = new Thread(new ThreadStart(mt1.ThreadFonction));
    t1.Start();
    MonThread mt2 = new MonThread(10);
    Thread t2 = new Thread(new ThreadStart(mt2.ThreadFonction));
    t2.Start();
    }
    }
    }
    // En .Net 2
    // Il suffit d'utiliser ParameterizedThreadStart
    using System;
    using System.Threading;
    public class Exemple
    {
    public static void Main()
    {
    Exemple e = new Exemple();
    }
    private Thread t;
    public Exemple()
    {
    t = new Thread(new ParameterizedThreadStart(IncrementToTen));
    t.Start(1);// Le parametre est passé dans la méthode Start()
    }
    public void IncrementToTen(object temp)
    {
    int i = (int)temp;
    while(i < 10) i++;
    Console.WriteLine(i.ToString());
    }
    }

Edit : En effet, désolé, je n'avais pas fait attention au site en question .. x)

28/11/2011, 16h46
olibara

Merci Aeronia

Bon mais si je comprends bien, la solution c'est de passer par une classe qui va servir de contenant aux proprietés nécessaire a la methode !

C'est un peu ce que j'etais en train de conclure egalement...

D'autres confirmations ou remarques a ce sujet ?
28/11/2011, 17h21
DonQuiche

Citation:

Envoyé par olibara

Bon mais si je comprends bien, la solution c'est de passer par une classe qui va servir de contenant aux proprietés nécessaire a la methode !

C'est exactement cela. D'ailleurs, lorsqu'un lambda est créé dans les versions 3.5 et supérieures, le compilateur génère typiquement une classe cachée contenant les données à utiliser et/ou un emplacement pour le résultat. Sauf s'il n'y a aucun argument ni valeur de retour à stocker bien sûr.

Manuellement, cela peut être fait de plusieurs façons :
* Thread.Start est un membre d'instance
* Thread.Start reçoit en argument une instance sur laquelle travailler
* Passer par des champs statiques.
28/11/2011, 17h28
antoine.debyser

Bonjour,

Citation:

Envoyé par olibara

Mais ca me semblait plus "bricolage" et sans etre certain que ca réponde au besoin
J'avais donc a priori négligé cette possibilité

Pour le coup le BackgroundWorker n'est pas du bricolage, Il a été conçus dans un but, pourvoir transmettre des événements de progression du Thread, ces événements ne générent pas de "cross-thread exception", ce qui permet de brancher directement l'IHM dessus.

Citation:

Envoyé par olibara

Bon mais si je comprends bien, la solution c'est de passer par une classe qui va servir de contenant aux propriétés nécessaire a la methode !

Dans le cadre d'un BackgroundWorker, tu ne peux effectivement passé qu'un argument. Et donc tu es obligé de créer une classe ou une structure regroupant tes divers paramètres.

Citation:

Envoyé par olibara

D'autres confirmations ou remarques a ce sujet ?

Oui, le plus difficile avec le multi-thread c'est la synchronisation. Plusieurs threads ne devraient pas lire et écrire sur la même variable en même temps (Il y a des objets de synchronisation pour ça).
Sinon il faut éventuellement prévoir un moyen propre d'annuler le thread.
Attendre correctement la fin du thread, etc...
28/11/2011, 17h59
olibara

Merci a tous

Bon et bien me voila en chemin, je vais commencer par uncapsuler la methoe en question dans une nouvelle classe pour la cause ;)
28/11/2011, 18h00
DonQuiche

Citation:

Envoyé par antoine.debyser

Plusieurs threads ne devraient pas lire et écrire sur la même variable en même temps (Il y a des objets de synchronisation pour ça).

Attention, cette remarque est essentiellement fausse. Deux threads peuvent très bien lire et écrire simultanément dans une même variable dans certains cas (1). Et, réciproquement, le fait que deux threads ne puissent pas lire et écrire dans une même variable à la fois ne garantit pas pour autant qu'il n'y ait pas de problème (2).

Il faut davantage approcher les problèmes de synchronisation comme l'on approche les transactions sur une base de données : ce qui compte c'est que toute modification de l'état soit consistante et que deux modifications simultanées ne puissent pas se corrompre l'une et l'autre. Le "C" et le "I" de ACID.

Exemple 1 : L'explorateur de fichiers effectue une série de copie de fichiers sur un thread. Son UI est mise à jour une fois par seconde et affiche le dernier fichier traité. Le thread de fond peut très bien assigner "lastFile" et le thread UI lire "lastFile" sans qu'une synchronisation soit nécessaire.

Exemple 2 : Une structure de données (liste par exemple) basée sur un tableau "items" d'une part et "count" d'autre part. Si l'on veut ajouter un élément il ne suffit pas de verrouiller d'abord "items", d'ajouter l'élément à i=2, relâcher le verrou puis verrouiller "count" pour le mettre à 3. En effet, entre la fin du premier verrou et le début du second, un thread aurait pu retirer l'élément à "i=1" (l'ancienne queue de la liste) et mettre "count" à 2. On se retrouverait alors avec "count" à 3 et "items" contenant "A, null, C".

La solution ici est d'avoir un seul verrou commun pour tous les états ("count" et "items") ou un système de verrous hiérarchisés (verrouiller items, verrouiller count, relâcher count, relâcher items) avec un priorité bien établie pour éviter les deadlocks.
28/11/2011, 18h09
youtpout978

pour passer plusieurs paramètre a mon thread je mettais tout dans un objet et de l'autre coté je castais l'objet avec le bon type, je suis pas sur que ça soit le plus propre non plus
28/11/2011, 18h14
DonQuiche

Citation:

Envoyé par youtpout978

pour passer plusieurs paramètre a mon thread je mettais tout dans un objet et de l'autre coté je castais l'objet avec le bon type, je suis pas sur que ça soit le plus propre non plus

Bof. Ca n'a vraiment rien de sale. Même si, personnellement, je préfère créer une instance avec une méthode Run et passer un délégué vers Run à Thread.Start.
29/11/2011, 13h35
antoine.debyser

Citation:

Envoyé par DonQuiche

Attention, cette remarque est essentiellement fausse. Deux threads peuvent très bien lire et écrire simultanément dans une même variable dans certains cas (1). Et, réciproquement, le fait que deux threads ne puissent pas lire et écrire dans une même variable à la fois ne garantit pas pour autant qu'il n'y ait pas de problème (2).

Très bonne précision de ma pensée.