[Multithreading] Thread ou non?

Bonjour,

dans le cadre du d�veloppement d'une petite application visant � comparer 2 dossiers ensemble, je me vois dans l'interrogation suivante:

Est ce que je peux cr�er un Thread ou plusieurs, qui, pour parfaire ma comparaison, effectueraient plusieurs choses, par ex:

- Un thread qui tourne et qui liste tous les r�pertoires d'un dossier A
- Un thread qui tourne et qui liste les r�pertoires d'un dossier B
- Un thread qui en permanence, � chaque lecture de r�pertoire, compare les chemins d'acc�s.

Je ne sais pas vraiment comment je pourrai d�velopper mon appli pour qu'elle compare mes r�pertoires, aussi je me pose la question des threads, qu'en dites vous?

merci d'avance

Beaucoup de thread pour rien?
Si tu penses que les actions vont prendre beaucoup de temps, tu peux commencer par d�couper en seulement deux threads: un pour l'IHM et un second pour la r�alisation de la comparaison. Ensuite travaille plus sur l'algo utilis� pour comparer, c'est � ce niveau que tes gains seront les plus importants.

Une r�gle g�n�rale en d�veloppement: n'utiliser des threads que quand on ne peut pas faire autrement. C'est comme les pointeurs en c++.
D'apr�s la description de ton programme, je ne pense pas que tu aies besoin de threads. A moins que ce ne soit � but didactique?

Citation:

---

n'utiliser des threads que quand on ne peut pas faire autrement.

---

Ce n'est vrai que pour un syst�me mono-c�ur.
Dans le cas g�n�ral, utiliser des threads permet de mieux exploiter la puissance de la machine, mais �a n�cessite de faire gaffe � la synchronisation qui aura d'ailleurs un co�t.

Exact, je suis all� un peu vite. Je devrais ajouter: "quand on a peu de connaissances sur les threads".

Il faut dire que r0d a raison, les erreurs � cause de thread ne sont pas reproductibles et difficilement d�bogable... Bonjour le temps perdu pour rien... :aie:
Cel� dit, sur du multi-coeur, �a peut consid�rablement acc�l�rer les calculs.

Enfin, ici pour faire des recherches � deux endroits diff�rents, si c'est sur le m�me disque, 2 threads �a va pas aider... Pas du tout!:aie:

(Acharnons-nous;) ):J'ai trouv� la r�ponse de Rod un peu rapide. Moi, comme dit dans mon premier mail, j'aime bien les solutions � 2 thread: un pour l'IHM et un pour le boulot. De m�me, dans des applis r�seaux, avoir un thread d�di� aux coms, pour les applis serveurs, un thread pour le listen, et un thread pour tous les clients). Mais, en g�n�ral, j'essaye de ne pas aller au del� de 2 ou 3 threads. Apr�s, � mon avis, la complexit� devient un facteur dissuasif (pb de synchro, s�curisation �changes, etc...).

Bon ok, je vais �tre plus pr�cis. Le PO n'a pas parl� d'IHM, et je ne vois pas en quoi son probl�me n�cessite plusieurs threads. De plus, dans 99% des cas, et en particulier sur ce type de programme, les quelques cycles que l'on va gagner en utilisant plusieurs coeurs ou plusieurs processeurs ne valent pas l'effort � mettre en oeuvre pour faire �a bien, quand on connais mal le sujet, ce qui me semble �tre le cas du PO sinon il n'aurait pas pos� cette question ici.

Ensuite effectivement, dans certains cas extr�mement marginaux (ou dans une approche didactique), il peut �tre utile d'utiliser plusieurs threads, mais je crois que ce n'est pas le cas ici (je me trompe peut-�tre).

Et, de fa�on g�n�rale, �a fait des ann�es que je r�pond � des questions sur divers forum de dev, et l'exp�rience a montr� que si la question ne sp�cifie pas des contraintes particuli�res, le meilleur conseil que l'on puisse donner sera de faire au plus simple.

My cent.

Salut,

Personnellement, je suis tout � fait d'accord avec le point de vue de r0d...

Trop souvent, les dev partent "en vrille" parce que le d�veloppeur a voulu aller chercher la complexit� l� o� il n'y avait a priori pas besoin d'aller la chercher.

De m�me, il n'est pas rare de voir sur les fora que les gens qui veulent r�pondre partent sur des consid�rations (application avec IHM... mais est-ce obligatoire :question: service r�seau, mais l� aussi, est-ce n�cessaire :question: multi ou mono processeur/core :question:) qui, si elles peuvent s'av�rer utiles n'en vont pas moins s'�carter de l'objectif premier de la personne qui pose la question.

De mani�re g�n�rale, la solution la meilleure est toujours la plus simple, et, quand on s'attaque au probl�me des threads, il faut quand m�me avouer que, ainsi que l'a signal� r0d, cela va immanquablement amener de la complexit� dans la gestion.

Maintenant, nous sommes bien d'accord sur l'�norme avantage que peut repr�senter la gestion multi-thread�e d'une application, d'autant plus que les coeurs/processeurs ont actuellement tendance � se multiplier comme moustiques en �t�...

Mais, de l� � pr�coniser d'office l'utilisation de threads alors qu'il y a surement des optimisation d'algorithmes plus indispensables � proposer, cela me ressemble � vouloir chasser un moustique avec un canon :P

Je crois donc en d�finitive que le mieux � faire est de conseiller d'abord de faire l'essai en mono thread, et d'envisager de passer en version multi-thread uniquement s'il s'av�re que le traitement est *r�ellement* et *significativement* trop long.

Disons qu'il y a 2 �coles. Parlons seulement de la 1�re �cole.

Le multi-thread, c'est tr�s facile quand il n'y aucun risque de conflit, tout thread est ind�pendant et a une action confin�e.
C'est parfois le cas dans le calcul scientifique. L�, je dirais qu'il y a tr�s peu de risque de se tromper, et les erreurs sont reproductibles.

Quand c'est du multi-thread "de gestion", c'est pas pareil, l� les emmerdes arrivent quand on connait pas bien.

Ca part en vrille non? Il me semble que ma premi�re r�ponse �tait � peu pr�s dans l'esprit de ce qui a �t� dit pr�c�demment:

Citation:

---

Envoy� par 3DArchi

Beaucoup de thread pour rien?
Si tu penses que les actions vont prendre beaucoup de temps, tu peux commencer par d�couper en seulement deux threads: un pour l'IHM et un second pour la r�alisation de la comparaison. Ensuite travaille plus sur l'algo utilis� pour comparer, c'est � ce niveau que tes gains seront les plus importants.

---

La partie importante pour moi �tait bien:

Citation:

---

Ensuite travaille plus sur l'algo utilis� pour comparer, c'est � ce niveau que tes gains seront les plus importants.

---

Apr�s, Rod, ta r�ponse �tait intrigante: je vois souvent des r�ponses mettant en garde contre le multi threading, sans que je comprenne bien pourquoi (l'absence de ma�trise n'�tant pas une bonne excuse � mon sens). Si vous voulez continuer ce d�bat, je propose qu'on ouvre un autre poste plus sp�cifique sur le multi threading: avantage/inconv�nient.

Je ne sais pas trop, mais je n'ai pas l'impression que nous soyons sorti du sujet, puisqu'en discutant sur les thread, nous essayons de r�pondre � la question pos�e, finalement. Je suis d'avis d'attendre une nouvelle intervention de Freud44 avant de continuer :)

edit: en ce qui me concerne, j'�tais intervenu surtout parce que je ne comprenais pas pourquoi tu parlais d'IHM

Citation:

---

Envoy� par r0d

Je ne sais pas trop, mais je n'ai pas l'impression que nous soyons sorti du sujet, puisqu'en discutant sur les thread, nous essayons de r�pondre � la question pos�e, finalement. Je suis d'avis d'attendre une nouvelle intervention de Freud44 avant de continuer :)

---

OK

Citation:

---

Envoy� par r0d

edit: en ce qui me concerne, j'�tais intervenu surtout parce que je ne comprenais pas pourquoi tu parlais d'IHM

---

C'�tait g�n�rique. IHM=ce que tu veux pour dire � l'utilisateur que l'appli est encore vivante: une led qui clignote, un boite de dialogue, des '.' sur une console, etc...

Je suis d'accord avec R0d.
Il suffit d'utiliser la programmation de threads quand on ne peut pas faire autrement pr�f�rablement et contrairement � ce que l'on pourrait penser cela n'accroit pas forc�ment les performances de traitement car l'OS doit commuter d'une tache � une autre fr�quemment.
Maintenant il faut faire des essais dans son application voir s'il y a un gain r�el en performances.

Citation:

---

Envoy� par Freud44

- Un thread qui tourne et qui liste tous les r�pertoires d'un dossier A
- Un thread qui tourne et qui liste les r�pertoires d'un dossier B
- Un thread qui en permanence, � chaque lecture de r�pertoire, compare les chemins d'acc�s.

---

Son probl�me est de parcourir deux r�pertoires pour les comparer.
Quel gain peut il gagner avec des threads?
Pour moi, le point bloquant sur les performances dans son probl�me sont les acc�s disque pour r�cup�rer les info des r�pertoire.
Je ne pense pas qu'avoir deux thread pour lister ces repertoires va g�n�rer un gain.

Par contre utiliser des thread pour faire la comparaison pourrais �tre int�ressant, si la liste est grande.

Citation:

---

Envoy� par Mongaulois

Son probl�me est de parcourir deux r�pertoires pour les comparer.
Quel gain peut il gagner avec des threads?

---

A priori, pas grand-chose.

Si les deux r�pertoires sont sur le m�me disque, il va probablement y perdre beaucoup, s'ils sont sur des disques diff�rents, peut-�tre va-t-il gagner un peu.

Si le traitement de comparaison est lourd (par exemple, une fois un fichier commun trouv�, il calcule les diff�rences sur ce fichier), il peut aussi y avoir un gain.

C'est � peu pr�s tout ce que je vois.