Pourquoi les fils pourraient-ils être considérés comme "mauvais" ?

Question

Je lisais le FAQ SQLite et je suis tombé sur ce passage :

Les fils sont mauvais. Évitez-les.

Je ne comprends pas bien l'affirmation "Le pain est mauvais". Si c'est vrai, alors quelle est l'alternative ?

Ma compréhension superficielle des fils est la suivante :

• Les fils de discussion permettent la concurrence. Sinon, la puissance du processeur sera gaspillée à attendre des E/S lentes (par exemple).
• Mais l'inconvénient est que vous devez synchroniser votre logique pour éviter la contention et que vous devez protéger les ressources partagées.

Note : Comme je ne connais pas les fils de discussion sur Windows, j'espère que la discussion se limitera aux fils de discussion sur Linux/Unix.

Answer 1

Les fils ne sont pas plus "diaboliques" que les marteaux, les tournevis ou tout autre outil ; il faut simplement être habile pour les utiliser. La solution n'est pas de les éviter, mais de s'instruire et d'améliorer ses compétences.

Answer 2

Créer un grand nombre de threads sans contrainte est en effet un mal. L'utilisation d'un mécanisme de pooling (threadpool) atténuera ce problème.

Une autre façon pour les threads d'être "mauvais" est que la plupart du code du framework n'est pas conçu pour gérer des threads multiples, vous devez donc gérer votre propre mécanisme de verrouillage pour ces structures de données.

Les fils sont une bonne chose, mais il faut réfléchir à comment et quand les utiliser et ne pas oublier de mesurer s'il y a vraiment un avantage en termes de performances.

Answer 3

Un fil est un peu comme un procédé léger. Il s'agit d'un chemin d'exécution indépendant au sein d'une application. Le thread s'exécute dans le même espace mémoire que l'application et a donc accès à toutes les mêmes ressources, objets globaux et variables globales.

Ce qui est bien avec eux, c'est que vous pouvez paralléliser un programme pour améliorer les performances. Quelques exemples : 1) Dans un programme d'édition d'images, un thread peut exécuter le traitement des filtres indépendamment de l'interface graphique. 2) Certains algorithmes se prêtent à plusieurs threads.

Qu'est-ce qu'ils ont de mauvais ? Si un programme est mal conçu, ils peuvent conduire à des problèmes de blocage où les deux threads attendent l'un de l'autre pour accéder à la même ressource. Et deuxièmement, la conception du programme peut devenir plus complexe à cause de cela. De plus, certaines bibliothèques de classes ne prennent pas en charge le threading. Par exemple, la fonction "strtok" de la bibliothèque C n'est pas "thread safe". En d'autres termes, si deux threads l'utilisaient en même temps, ils détruiraient les résultats de l'autre. Heureusement, il existe souvent des alternatives thread safe... par exemple, la bibliothèque boost.

Les fils ne sont pas mauvais, ils peuvent même être très utiles.

Sous Linux/Unix, le threading n'a pas été bien supporté dans le passé, bien que je crois que Linux a maintenant le support Posix thread et d'autres unités supportent le threading maintenant via des bibliothèques ou nativement. i.e. pthreads.

L'alternative la plus courante au threading sous les plateformes Linux/Unix est le fork. Le fork est simplement une copie d'un programme, y compris les handles de fichiers ouverts et les variables globales. fork() retourne 0 au processus enfant et l'identifiant du processus au parent. C'est une ancienne façon de faire les choses sous Linux/Unix mais elle est toujours bien utilisée. Les threads utilisent moins de mémoire que fork et sont plus rapides à démarrer. De plus, les communications entre processus demandent plus de travail que les simples threads.

Answer 4

Pour toute application qui nécessite une exécution stable et sûre pendant de longues périodes sans défaillance ni maintenance, les threads sont toujours une erreur tentante. Ils s'avèrent invariablement être plus de problèmes qu'ils n'en valent la peine. Ils produisent des résultats rapides et des prototypes qui semblent fonctionner correctement, mais après quelques semaines ou mois d'exécution, vous découvrez qu'ils ont des défauts critiques.

Comme l'a mentionné une autre personne, dès que vous utilisez ne serait-ce qu'un seul thread dans votre programme, vous avez ouvert un chemin non déterministe d'exécution du code qui peut produire un nombre presque infini de conflits de timing, de partage de la mémoire et de conditions de course. La plupart des expressions de confiance dans la résolution de ces problèmes sont exprimées par des personnes qui ont appris les principes de la programmation multithread mais qui n'ont pas encore fait l'expérience des difficultés à les résoudre.

Les fils sont mauvais. Les bons programmeurs les évitent quand c'est humainement possible. L'alternative de la bifurcation a été proposée ici et c'est souvent une bonne stratégie pour de nombreuses applications. La notion de décomposition de votre code en processus d'exécution séparés qui fonctionnent avec une certaine forme de couplage lâche s'avère souvent être une excellente stratégie sur les plates-formes qui la supportent. Les threads exécutés ensemble dans un seul programme ne sont pas une solution. Il s'agit généralement de la création d'une faille architecturale fatale dans votre conception qui ne peut être réellement corrigée qu'en réécrivant l'ensemble du programme.

La récente dérive vers la concurrence orientée événement est une excellente innovation en matière de développement. Ces types de programmes font généralement preuve d'une grande endurance après leur déploiement.

Je n'ai jamais rencontré un jeune ingénieur qui ne pensait pas que les fils étaient formidables. Je n'ai jamais rencontré un ingénieur plus âgé qui ne les fuyait pas comme la peste.

Answer 5

En tant qu'ingénieur plus âgé, je suis tout à fait d'accord avec l'énoncé suivant. réponse de Texas Arcane .

Les fils sont très mal parce qu'ils provoquent des bogues extrêmement difficiles à résoudre. J'ai littéralement passé des mois à résoudre des conditions de course sporadiques. Par exemple, une fois par mois, les tramways s'arrêtaient soudainement au milieu de la route et bloquaient le trafic jusqu'à ce qu'ils soient remorqués. Heureusement, je n'ai pas créé le bug, mais j'ai dû passer 4 mois à plein temps pour le résoudre...

Il est un peu tard pour ajouter à ce fil de discussion, mais je voudrais mentionner une alternative très intéressante aux threads : la programmation asynchrone avec des co-routines et des boucles d'événements. Cette méthode est supportée par de plus en plus de langages et ne présente pas le problème des conditions de course comme le multithreading.

Il peut remplacer le multithreading dans les cas où il est utilisé pour attendre des événements provenant de sources multiples, mais pas lorsque les calculs doivent être effectués en parallèle sur plusieurs cœurs de CPU.