Bonjour à tous,

Je suis actuellement sur un projet récupérant des données utilisateurs depuis 4 fichiers étant sous des formats simples (txt, csv, etc). Étant donné que je n'avais jamais véritablement touché aux threads avant ce jour, j'ai eu envie d'essayer de les implémenter pour la lecture de mes fichiers.

J'ai lu ce sujet https://openclassrooms.com/forum/sujet/c-multithreading-2 et une question m'est venue du coup, au vu des réponses qui y sont apportées : multithread ou pas ? Pensez-vous qu'il y ait un réel intérêt à ce que je répartisse la charge pour le traitement des fichiers ainsi, ou bien une lecture en séquentielle fera tout aussi bien l'affaire ? (après l'avoir lu, je pensais passer en séquentielle même si en multithread, ça fait aussi le café et marche comme désiré)

Dans ce sujet, il y avait également un point assez vague à mes yeux, mais quand, ou plutôt dans quel cas faudrait-il opter pour du multithread finalement ? Quelle(s ?) en serai(en)t les plus-values ?

Merci à vous tous pour vos précisions, détails et éclaircissement !

Max

-
Edité par MaximeB25 8 juillet 2019 à 9:48:02

Lu'!

Si ton objectif c'était d'aller plus vite alors clairement non, aucun intérêt ici puisque ton disque dur est le facteur limitant et que lui n'est pas capable de faire plusieurs actions en même temps.

MaximeB25 a écrit:

(... même si en multithread, ça fait aussi le café et marche comme désiré)

Tu es sûr de ça ? Le problème du multi-thread, c'est que c'est généralement assez dur à tester .

Pour ce qui est des cas d'usage du multi-thread, il y en a pas mal du fait d'exploiter le parallélisme pour gagner de la vitesse sur les traitements au découplage de tâches indépendantes (et éventuellement communicantes).

Salut,

L'objectif était d'aller plus vite en effet (mais c'était avant que je ne tombe sur ce sujet de 2015). Dans mon cas, il s'agit "juste" de checker et de potentiellement récupérer des données ainsi que de les formater autrement si besoin (d'ailleurs je ne suis pas sûr, et c'est peut être une mauvaise pratique, mais pour les tests, comme les threads étaient dans une méthode, c'était cette méthode qui validait ou non les différents intervenants. (D'où ma remarque "ça marche comme désiré".))

Ma décision du multi était surtout pour dire "youpi multithread, ça fonctionne " et pour en découvrir un peu plus sur eux à vrai dire. Ce n'est qu'en cherchant un peu que j'ai commencé à découvrir l'iceberg, mais mutli ou pas ne changeait pas mon architecture/algo, donc j'avais poursuivi ainsi par curiosité.

Merci pour ta réponse et les détails apportés en tout cas !

Question tout à fait stupide : il n'y a "que" le disque dur qui, de par ses caractéristiques et sa vitesse, nous limite ? Ou bien il existe aussi d'autres paramètres à prendre en compte mais qui sont tout à fait négligeables par rapport au dd ?

MaximeB25 a écrit:

mais pour les tests, comme les threads étaient dans une méthode, c'était cette méthode qui validait ou non les différents intervenants. (D'où ma remarque "ça marche comme désiré".))

Oui mais la difficulté n'est pas là . La difficulté c'est qu'il y a toujours un risque non-négligeable que le bon comportement d'une fonction multi-threadée soit dépendant de la manière dont sont ordonnancés les threads durant l'exécution. C'est l'un des points "contre" du multi-threading : c'est difficile à valider par du test.

MaximeB25 a écrit:

Question tout à fait stupide : il n'y a "que" le disque dur qui, de par ses caractéristiques et sa vitesse, nous limite ? Ou bien il existe aussi d'autres paramètres à prendre en compte mais qui sont tout à fait négligeables par rapport au dd ?

Potentiellement tout périphérique avec lequel tu fais des entrées sorties, qui demandent généralement à ce que les ordres soient de toute façon rendus séquentiels par le canal par lequel on communique avec lui.

Hello,

Pour ma part, je fait des threads et des forks uniquement si la partie appelée est écrit sans mutation, voir de manière fonctionnelle.

Ainsi, l'ordre d'appels ne change rien, et c'est la ma méthode créant des threads de donner les bons arguments aux fonctions appelée.

Je n'ai jamais fait de threads en C++, mais en Ruby par exemple, il suffis par la suite d'attendre la fin des threads avec un `join`

Les gains de perfs sont rarement spectaculaire, car ce sera le thread le plus long qui sera la référence de temps.

Ksass`Peuk a écrit:

Oui mais la difficulté n'est pas là . La difficulté c'est qu'il y a toujours un risque non-négligeable que le bon comportement d'une fonction multi-threadée soit dépendant de la manière dont sont ordonnancés les threads durant l'exécution. C'est l'un des points "contre" du multi-threading : c'est difficile à valider par du test.

[...]

Potentiellement tout périphérique avec lequel tu fais des entrées sorties, qui demandent généralement à ce que les ordres soient de toute façon rendus séquentiels par le canal par lequel on communique avec lui.

Ok je vois mieux le truc ! Merci d'avoir détaillé

@necros211 ça marche merci ! Oui idem en C++, join() les threads.

Salut,

Pour la lecture des fichiers, comme c'est séquentiel, pas de multithread.

Par contre, pour tout ce qui est calculatoire et indépendant, on peut en utiliser.

ça marche, merci Fvirtman

Merci à vous tous pour vos réponses