Discussion :

[Freud44]

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

[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.

[r0d]

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?

[loufoque]

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.

[r0d]

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

[poukill]

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...
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!

[3DArchi]

(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...).

[r0d]

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.

[koala01]

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 service réseau, mais là aussi, est-ce nécessaire multi ou mono processeur/core ) 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

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.

[HanLee]

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.

[3DArchi]

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:

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:

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.

[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

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

[3DArchi]

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

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...

[Mat.M]

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.

[yan]

- 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.

[JolyLoic]

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.