Présentation d'un tutoriel au sujet de l'utilisation du multithreading

Version imprimable

03/11/2012, 00h57
Immobilis

Présentation d'un tutoriel au sujet de l'utilisation du multithreading

Bonjour à tous,

J'ai écrit un tutoriel à propos de l'utilisation du multithreading dans une application de traitement par lots (batch): http://immobilis.developpez.com/tuto...tielle-batchs/

N'hésitez pas à me dire ce que vous en pensez. Si vous avez des questions n'hésitez pas à les poster ici, j'aurai plaisir à y répondre.

Merci d'avance.

Immo
25/11/2012, 12h38
Nathanael Marchand

Question bête mais pourquoi ne pas utiliser la TPL ? :aie:
25/11/2012, 13h04
Immobilis

Salut

Citation:

Envoyé par Nathanael Marchand

TPL ?

La quoi? :aie:

[EDIT]La Task Parallel Library? Ben je connaissais pas.

A l'époque, j'ai trouvé une solution avec mes connaissances du moment et le Framework imposé (3.5). Bon, pour le tutoriel , j'ai utilisé le FW 4.5 et VS Ultimate. Je vais regarder ça.

Merci :)
06/12/2012, 12h46
Immobilis

Citation:

Envoyé par Nathanael Marchand

pourquoi ne pas utiliser la TPL ? :aie:

Effectivement, cette bibliothèque semble très pratique.

Toutefois, je n'ai pas trouvé de méthode/implémentation pour reproduire le comportement "flux tendu". Il y a bien les "tâches de continuation" mais il faudrait gérer la possibilité de démarrer un nombre variable de tâches (ex: 10). Une fois finie, chaque tâche doit lancer la suivante jusqu'à ce que toute la pile ait été traitée. C'est faisable, mais du coup on ne profite pas forcement des capacités de la TPL.

Sachant qu'on ne connait pas le nombre de tâches ni le nombre de flux simultanés, l'utilisation de "child task" ou "nested task" ne nécessiterait-il pas la création d'une fonction récursive? Il faut que je teste cela, mais il me semble que la tâche parent ne serait pas collectée par le garbage collector tant que tous les enfants n'ont pas été collectés. Du coup, j'ai peur que des ressources partagées (ex: traitement sur des fichiers) ne restent bloquées.

Dans mon exemple, c'est le manager qui créé les tâches. Il y a donc pas d'interactions entre ces dernières.

Qu'en penses-tu?
06/12/2012, 13h17
Nathanael Marchand

J'ai pas tout compris :aie:

T'as un cas d'utilisation simple, que j'y reflechisse ?

Je dois préparer une formation pour les consultants de ma boite sur la TPL, mi janvier. Quand j'aurais un peu de temps, je la coucherai sur un article, n'hésite pas à m'y indiquer tes préoccupations, ca ne peut que m'aider :ccool:
06/12/2012, 22h41
Immobilis
Citation:

Envoyé par Nathanael Marchand

T'as un cas d'utilisation simple, que j'y reflechisse ?

Le cas du tuto: http://immobilis.developpez.com/tuto...atches/#LIII-F
1. Faire 1000 appels sur un service web;
2. Enregistrer la réponse qui peut arriver après un temps d'attente de 1 à 10 secondes.
3. Mettre le moins de temps possible.
A+
07/12/2012, 10h28
Nathanael Marchand

Je comprends pas tout à fait ta problématique de flux tendu mais bon... :mrgreen:
Pour le coup, Task derrière c'est plus ou moins le même principe que ThreadPool...
Quand tu fais 1000appels aléatoires, tu a pas peur que le facteur aléatoire influence les tests ? Il faudrait vérifier que le temps moyen soit identique à chaque test.
07/12/2012, 11h18
Immobilis
Citation:

Envoyé par Nathanael Marchand

Je comprends pas tout à fait ta problématique de flux tendu mais bon... :mrgreen:

A mince. Du coup, tu n'est peut-être pas le seul. Je précise donc.

Dans le tutoriel, je présente trois façons de faire du multithreading. Les deux premières sont celles qu'on trouve couramment sur internet:
1. Tous les threads en même temps => écarté car surcharge le serveur;
2. Une salve de threads (en utilisant le pool et un waithandle) => écarté car WaitAny ne permet pas de savoir combien de threads ont terminé (donc on ne sait pas combien on peut en relancer) et WaitAll provoque des temps morts (des threads ont fini mais le signal n'est pas envoyé car d'autres sont encore en train de travailler).
Le terme "flux tendu" indique qu'il ne doit pas y avoir de temps mort. Grâce aux évènements, chaque thread indique quand il a fini. Le manager peut lancer un nouveau thread dès qu'un se libère. On maintient un nombre déterminé de threads en action. Cela permet de tirer parti des ressources des différents systèmes au maximum (voir la comparaison des temps).

Est-ce plus clair? :oops:
07/12/2012, 11h49
antoine.debyser

Bonjour,

Plusieurs point m'avez surpris à la lecture du tutoriel.
Notamment sur les liens entre les résultats et la version suivante. Par exemple pas besoin de thread pool pour pouvoir répondre à tous les besoins.

Mais revenons au sujet, à la lecture du cas du thread pool, je me suis posé la question suivante :
- la découpe en "salve" de thread, comme tu dis, est elle vraiment nescessaire? n'est ce pas dans le périmètre du thread pool?

Apres test, en local, le thread pool semble bien répondre à ce besoin, c'est à dire que tous les thread ne sont pas lancé dans la foulé. Il est possible de définir la limite soit même, Bref seul "i" thread sur les "n" tourne en même temps.

Du coup on peut faire un "WaitAll", pour attendre la fin de tous les thread, il n'y aurra pas de temps de mort, on aurra une vrai mesure du temps total, et la possibilité d'agrégé tous les retours.

Au niveau de TPL, il me semble que créer une class dérivé de TaskScheduler permet d'obtenir le meme comportement.
Le principe de chainage correspond à un autre besoin. Celui qu'une tache ne doit pas être exécuté avant une autre.
07/12/2012, 12h41
Nathanael Marchand

Ah ben là, en effet je confirme les propos de antoine.debyser, dans le cas du ThreadPool ca fait double pooling et c'est déconseillé :)

Cependant, j'ai déjà eu des cas ou une librairie tierce (Oracle pour ne pas la citer) utilisait également le ThreadPool et on avait des conflits: On crééait n taches via le ThreadPool, chaque tâche ouvrait une connection base de données. Or sur Oracle, dans le driver, l'ouverture se base aussi sur le ThreadPool et l'action n'était jamais dépilée : deadlock !
07/12/2012, 12h53
Immobilis

Citation:

Envoyé par antoine.debyser

Apres test, en local, le thread pool semble bien répondre à ce besoin, c'est à dire que tous les thread ne sont pas lancé dans la foulé. Il est possible de définir la limite soit même, Bref seul "i" thread sur les "n" tourne en même temps.

C'est vrai :ccool: mais...

Citation:

Envoyé par antoine.debyser

Du coup on peut faire un "WaitAll", pour attendre la fin de tous les thread, il n'y aurra pas de temps de mort, on aurra une vrai mesure du temps total, et la possibilité d'agrégé tous les retours.

Mais il me semble bien que la méthode WaitHandle.WaitAll attend en paramètre un tableau de ManualResetEvent. Or ce tableau est limité à 64 éléments. Si on veut faire 1000 appels on est coincé.

A+
07/12/2012, 13h51
Nathanael Marchand

Citation:

Envoyé par Immobilis

ManualResetEvent. Or ce tableau est limité à 64 éléments. Si on veut faire 1000 appels on est coincé.

Ca c'est bien vrai et problématique et il faut souvent ruser :?
07/12/2012, 14h18
antoine.debyser

Citation:

Envoyé par Nathanael Marchand

Ca c'est bien vrai et problématique et il faut souvent ruser :?

Sous linux vu qu'il n'y a pas de WaitMutlipleObject, on aurait utilisé un sémaphore avec un compteur :ccool:

Et sinon je viens d'y penser, mais on peut faire un Parallel.For.
Bon ca ne se code vite et proprement que pour les cas simples.

J'avais oublié dans mon message précédent, mais chapeau bas pour le gestionnaire de tache dans le tuto. C'est une bonne base pour les applis qui sont limité à .Net 3.5
07/12/2012, 16h57
Nathanael Marchand

Citation:

Envoyé par antoine.debyser

Sous linux vu qu'il n'y a pas de WaitMutlipleObject, on aurait utilisé un sémaphore avec un compteur :ccool:

Ne pas oublier d'utiliser Interlocked.Increment et Interlocked.Decrement pour des opérations atomiques :)
07/12/2012, 21h00
Immobilis

Citation:

Envoyé par Nathanael Marchand

Ca c'est bien vrai et problématique et il faut souvent ruser :?

Je ne sais pas si on peut considérer cela comme une ruse mais avec la gestion des évènements il n'y a plus de limites.

Citation:

Envoyé par antoine.debyser

J'avais oublié dans mon message précédent, mais chapeau bas pour le gestionnaire de tache dans le tuto. C'est une bonne base pour les applis qui sont limité à .Net 3.5

Merci :) Il y a tout de même un inconvénient, c'est qu'on créé autant d'instances de thread qu'il y a de tâches. Toutefois cela ne se ressent pas sur les performances. En regardant le gestionnaire de tâches, le processus ne prend pas trop de mémoire.

A+
07/12/2012, 23h16
Nathanael Marchand

1 pièce(s) jointe(s)
J'ai fait mumuse avec un code proche de ta solution et en y ajoutant la TPL.
Ben pour tous, c'est grosso modo la même chose... J'ai pas fait l'étape sauvegarder dans un fichier car flemme mais ca n'a rien de bloquant.
A chaque fois on est capable de chronométrer le temps par appel et le temps total. Ca supporte aisément plus de 64 tâches (je n'utilise pas de WaitHandle.WaitAll)
En fait, ce qui est surtout déterminant (et en fait ce qui est complètement masqué dans ton article) c'est la capacité du client à traiter les tâches de manière concurrente. Tu remarqueras que dans mon exemple j'utilise un WCF en console pour avoir totalement la main sur le parallélisme. Toutes les requêtes sont indépendantes et une instance de service par requête.

Code:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.PerCall)]
Code:

1 2 3 4 5 <serviceBehaviors> <behavior name="HelloWorldBehavior"> <serviceThrottling maxConcurrentCalls="10"/> </behavior> </serviceBehaviors>
D'après moi c'est au fournisseur de brider son service en fonction de ce qu'il peut recevoir et non pas au consommateur. Du coup, y'a pas vraiment de raisons de brider côté client. Et quand bien même tu voudrais brider, tu pourrais totalement avec le sémaphore.
07/12/2012, 23h38
Nathanael Marchand

Erf, je reviens sur ce que j'ai dit. Quand on utilise des Thread à gogo ca fait planter le client car ca utilise trop de connections :)
Problème qu'on ne rencontre pas avec des pools de threads (ThreadPool et TPL)
Edit: Il suffit de placer un sémaphore autour de l'appel et ca fonctionne ;)
08/12/2012, 10h34
sisqo60

Bonjour,

Je trouve ton article très utile lorsqu'on développe sur des versions de framework antérieures au 4. Comme l'a très bien mis en évidence Nathanael Marchand, TPL est apparu avec le framework 4 qui a "simplifié" l'utilisation des threads, mais depuis le framework 4.5, il y a 2 nouveaux mots clés du langage, async et await, qui simplifient vraiment l'utilisation des threads contrairement à TPL.

Pour avoir passé du temps à jouer avec les thread, threadpool, backgroundworker et être passé à TPL puis à async programming, je trouve que les dév de Microsoft ont trouvé une très bonne solution pour simplifier l'utilisation des threads.

L'avez-vous testé?
08/12/2012, 14h12
Nathanael Marchand
Citation:

Envoyé par sisqo60

Pour avoir passé du temps à jouer avec les thread, threadpool, backgroundworker et être passé à TPL puis à async programming, je trouve que les dév de Microsoft ont trouvé une très bonne solution pour simplifier l'utilisation des threads.

async/await c'est très bien pour les cas simples d'asynchronisme. Mais on tombe très vite dans des pièges comme celui ci:
Code:

1 2 3 4 foreach(var toto in titi) { var tutu = await toto.DoAsync(); }
Le code ci dessus s'executera séquentiellement (un toto après l'autre) et non pas les toto en parallèle.
Car en effet, async/await gèrent l'asynchronisme, pas le parallélisme (différence fondamentale) :)
08/12/2012, 19h20
Immobilis
Citation:

Envoyé par Nathanael Marchand

J'ai fait mumuse avec un code proche de ta solution et en y ajoutant la TPL.

Tu t'es bien amusé je vois ça :mouarf: C'est très intéressant :ccool:

La méthode "E" est très chouette! Elle me semble la plus adaptée à mon besoin, car il me semble qu'elle permet de traiter les tâches de manière vraiment indépendante. La méthode Task.WaitAll(tasks.ToArray()) est aussi beaucoup plus élégante que mon PauseAndWait :king:

Les méthodes B et C partagent le compteur "c" ainsi que le "ManualResetEvent". Cela créé une certaine dépendance. Je suis un peu réservé du coup. Pour ceux qui voudraient utiliser ces méthodes, ne faudrait-il pas mettre ce bloc
Code:

1 2 3 4 if (Interlocked.Decrement(ref c) == 0) { wh.Set(); }
dans un try{ }finally{ } pour être certain de décrémenter le compteur. Dans le cas contraire, à moins de mettre un timeout, on attendra indéfiniment, non?

Dans la méthode "F", tu utilises le même client. Le Runtime utilise la même instance à l'exécution?

A+
08/12/2012, 21h25
Nathanael Marchand
Citation:

Envoyé par Immobilis

Tu t'es bien amusé je vois ça :mouarf: C'est très intéressant :ccool:

Oui, ton code m'a intrigué ;)

Citation:

Envoyé par Immobilis

Les méthodes B et C partagent le compteur "c" ainsi que le "ManualResetEvent". Cela créé une certaine dépendance. Je suis un peu réservé du coup.

Ca se factorise très bien dans une classe avec une méthode qui prendrait un Action en paramètre :)
Citation:
Envoyé par Immobilis

Pour ceux qui voudraient utiliser ces méthodes, ne faudrait-il pas mettre ce bloc

Code:

1 2 3 4 if (Interlocked.Decrement(ref c) == 0) { wh.Set(); }

dans un try{ }finally{ } pour être certain de décrémenter le compteur. Dans le cas contraire, à moins de mettre un timeout, on attendra indéfiniment, non?
En effet, j'ai continué a bidouiller après coup et quand j'ai eu des erreurs, m'en suis apercu ^^

Citation:

Envoyé par Immobilis

Dans la méthode "F", tu utilises le même client. Le Runtime utilise la même instance à l'exécution?
A+

Oui! Le client est le même, derrière par contre je suis pas allé vérifier mais il y a peut être un InnerChannel/requête.
09/12/2012, 00h09
Immobilis

2 pièce(s) jointe(s)

Très intéressant tout ça :ccool:

Citation:

Envoyé par Nathanael Marchand

D'après moi c'est au fournisseur de brider son service en fonction de ce qu'il peut recevoir et non pas au consommateur. Du coup, y'a pas vraiment de raisons de brider côté client.

Si on se base sur le comportement de IIS, c'est ce qui se produit. Pour autant, c'est quelque chose de difficile à mettre en place de manière efficace. Il n'y a qu'à voir les attaques DOS.

Citation:

Envoyé par Nathanael Marchand

Erf, je reviens sur ce que j'ai dit. Quand on utilise des Thread à gogo ça fait planter le client car ça utilise trop de connections :)

Laquelle de tes méthodes en particulier?

J'ai essayé 1000 appels avec la méthode "E" et j'ai eu un plantage à cause d'un Timeout. Du coup, j'ai testé sur une virtualbox avec Windows 2003 Server (histoire de voir comment réagit IIS). J'ai encore eu le plantage entre la 750e et 800e connexion. Je mets les logs de performance en PJ (Nat_000006.csv).

J'ai aussi testé la méthode du tuto et la méthode "E" avec 100 appels (idem PJ, Nat_000005.csv et un aperçu graphique).

Un truc me préoccupe, c'est le nombre de connections/utilisateurs anonymes courants. Dans le cas de la méthode "E", il ne cesse d'augmenter. Est-ce ce que tu voulais dire par

Citation:

Envoyé par Nathanael Marchand

Problème qu'on ne rencontre pas avec des pools de threads (ThreadPool et TPL)
Edit: Il suffit de placer un sémaphore autour de l'appel et ca fonctionne ;)

Pourtant on dirait que cela se produit quand même avec les Task. Comment placerais-tu ton sémaphore?

A+

C'était ma méthode B qui me posait soucis car apparemment tous les Threads partaient d'un coup et ca saturait le nombre de connection qu'un client pouvait faire. Du coup, j'ai mis un sémaphore comme ceci:

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
public void Do(int n)
{
	var c = n;
	var wh = new ManualResetEvent(false);
 
	var semaphore = new Semaphore(20, 20);
 
	for (int i = 0; i < n; i++)
	{
		var j = i;
		var thread = new Thread(() =>
			{
				try
				{
					semaphore.WaitOne();
					using (var asynchronousClient = new AsynchronousServiceReference.HelloWorldServiceClient())
					{
						asynchronousClient.HelloWorld("Toto");
						Console.WriteLine(j);
					}
				}
				finally
				{
					if (Interlocked.Decrement(ref c) == 0)
					{
						wh.Set();
					}
					semaphore.Release();
				}
			});
 
		thread.Start();
	}
 
	wh.WaitOne();
}

09/12/2012, 18h51
Immobilis

Et à propos du fait que, dans le cas de la méthode "E", le nombre de connections/utilisateurs anonymes courants ne cesse d'augmenter? A ton avis, comment résoudre ce problème?
09/12/2012, 21h55
Nathanael Marchand

Citation:

Envoyé par Immobilis

Et à propos du fait que, dans le cas de la méthode "E", le nombre de connections/utilisateurs anonymes courants ne cesse d'augmenter? A ton avis, comment résoudre ce problème?

As tu essayé le using autour du client ?
Mon code original ne faisait pas le Dispose.
09/12/2012, 23h31
Immobilis

Citation:

Envoyé par Nathanael Marchand

As tu essayé le using autour du client ?
Mon code original ne faisait pas le Dispose.

Oui, c'est pareil.
02/02/2013, 14h08
Immobilis

Salut,

Citation:

Envoyé par Nathanael Marchand

Je dois préparer une formation pour les consultants de ma boite sur la TPL, mi janvier.

Des news à propos de cette formation? :ccool:

A+
02/02/2013, 15h10
Nathanael Marchand

Citation:

Envoyé par Immobilis

Salut,
Des news à propos de cette formation? :ccool:

A+

Yay!
Je l'ai donné y'a deux semaines :)
Le webcast ainsi que les slides seront bientôt dispos sur mon blog :D

Fuseau horaire GMT +2. Il est actuellement 06h54.