Quelles sont les fausses idées qui dissuadent les gens d'utiliser des fils? [fermé]

Implémenter le threading dans un programme est difficile, oui, mais pourquoi certaines personnes ne les implémenteront-elles pas même quand il y en a un besoin évident.

Un exemple: le programme doit charger un ensemble de données à partir d'une base de données, la chose à faire serait d'établir la connexion et d'obtenir les données de la base de données dans un thread de travail, puis de les charger dans l'interface graphique, laissant le thread GUI réactif pour l'utilisateur .

Mais non, j'ai parlé à des gens qui semblent penser que les fils sont mauvais et mauvais et ainsi de suite et il faut les éviter à tout prix. J'ai même entendu dire qu'un instructeur de classe déconseillait l'utilisation de threads et ne voulait donc pas couvrir leur utilisation. QUOI???

Avec le matériel qui passe au multicœur, je pense que nous devons mieux comprendre les threads et ne pas avoir peur de les utiliser. Je trouve personnellement que c'est un sujet fascinant.

Alors, quelles sont les choses que vous avez entendues sur le filetage qui sont fausses?

L'enfilage est difficile

Sûr. Ça peut être. Cependant, les gens ont cette idée en tête que c'est si difficile, qu'ils ne prennent pas la peine d'essayer de le comprendre.

Ce n'est pas comme si c'était impossible.

Ce n'est pas la partie de threading qui est difficile, mais le besoin de synchronisation et tout le reste qui vient avec l'utilisation de threads. Dans votre exemple d'interface graphique, comment dites-vous au thread principal que l'ensemble de données est prêt à être consulté? Passez-vous tout un tas de rappels? Éparpillez-vous tout un tas de variables de contrôle dans votre code? Dans certains modèles d'interface graphique, par exemple Silverlight, il y a quelque chose appelé affinité de thread, ce qui signifie que vous ne pouvez pas accéder aux éléments d'interface graphique assis sur le thread principal à partir d'autres threads, vous devez donc vous éloigner pour faire savoir au thread principal que certaines informations sont prêt à être traité ultérieurement.

Je n'ai pas vraiment entendu de fausses choses sur les threads. Je viens de lire toute une série d'études de cas situationnelles sur la synchronisation étant une chienne quand l'algorithme que vous utilisez n'est pas intrinsèquement parallèle.

Le filetage résout tous vos problèmes

Si vous rencontrez des problèmes de performances, vous ne devez pas passer directement au threading.

Les fils sont légers

Les fils sont légers dans des dizaines et des années vingt. Générer des milliers de threads ne l'est pas.

L'enfilage est facile [Java]

Il est facile de créer des discussions, cela ne signifie pas que vous en profiterez.

Vous perdrez éventuellement tout gain de threading car la correction de bugs fous qui résulteront de l'utilisation de certaines bibliothèques / fonctions qui ne sont pas thread-safe (ce que vous ne saviez pas) nécessitera une synchronisation excessive.

Vous avez une probabilité beaucoup plus élevée de rencontrer un bug que vous ne pourrez pas corriger si vous utilisez des threads alors que vous ne le faites pas.

Pour résumer les raisons pour lesquelles les threads sont difficiles à utiliser: -
Vraies choses 1) Besoin de synchronisation et de décisions de conception prudentes sur ce qu'il faut verrouiller et quand le verrouiller
2) Aucun contrôle sur le flux de temps d'exécution
3) Débogage difficile
4) (Très peu fois) compatibilité de la plate-forme: - Les bibliothèques existent pour s'en occuper

False Things: -
1) Concepts confus de fonctions thread-safe et rentrantes
2) Les threads ont l'air bien sur le papier mais sont très difficiles à implémenter

Si vous ne voulez pas écrire de tests pour votre code, n'utilisez pas de threads.

Les threads ne sont pas destinés au programmeur type «copier-coller» qui ne comprend pas les fondamentaux sous-jacents du système d'exploitation et de l'architecture informatique. Étant donné que 90% des programmeurs ne connaissent que Java, ce ne sont vraiment pas les personnes qui devraient utiliser des threads. Java rend les threads "faciles" mais j'ai vu beaucoup de programmeurs qui pensent simplement que s'ils utilisent des structures synchronisées, leur code fonctionnera dans les threads ... euh non.

Cela étant dit, tout le monde doit commencer quelque part, ne faites pas votre premier projet de threading pour mettre à niveau le serveur principal de production de votre entreprise.

Un exemple: le programme doit charger un ensemble de données à partir d'une base de données, la chose à faire serait d'établir la connexion et d'obtenir les données de la base de données dans un thread de travail, puis de les charger dans l'interface graphique, laissant le thread GUI réactif pour l'utilisateur .

Je ne vois pas que cette situation représente une nécessité d'utiliser le filetage pour au moins 4 raisons:

1. La récupération des données doit être très rapide.

2. Dans de nombreuses applications du secteur d'activité, l'utilisateur n'a rien à voir avec l'application dans la seconde ou les deux secondes où il attend le résultat. De plus, l'utilisateur devra attendre que les données reviennent de quelque manière que ce soit pour terminer la tâche souhaitée. D'autre part, la requête pourrait être codée de manière intelligente de telle sorte qu'elle ne récupère qu'une page pleine d'informations à la fois et d'autres techniques d'optimisation pourraient aider le temps de réponse.

3. Dans les interfaces Web, des liens peuvent être rendus actifs concernant le modèle de thread.

4. Le threading ajoute de la complexité comme vous l'admettez, certains développeurs peuvent ne pas être en mesure d'ajouter des fonctionnalités ou de déboguer du code complexe.

Mon opinion est la suivante: utilisez le filetage lorsque vous le devez, car la maintenabilité et la fiabilité des logiciels sont plus précieuses pour une organisation que l'élégance du code.