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

12

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?

multithreading Tony le lion
la source
Les ratés et les sous-performants ne peuvent pas gérer les fils. La vraie question est: qu'allez-vous faire à ce sujet?
Job
3
Ce ne sont pas de fausses idées, mais les discussions doivent toujours être évitées. Faites votre architecture correctement afin que le support de threading soit déjà correctement géré et que chaque programmeur n'ait pas besoin de le faire lui-même. Une fois que les programmeurs apprennent à ajouter un fil à chaque situation, vous aurez de gros problèmes.
tp1
Permettez-moi de vous retourner la question. Vous êtes-vous demandé s'il existe des approches alternatives pour exploiter les capacités de traitement parallèle? Ou, est-ce que vous venez de passer directement au threading parce que certains livres blancs l'ont dit, ou peut-être parce que c'est ce que les meilleurs programmeurs ont trouvé cool? Personnellement, j'aime beaucoup mieux les processus légers qui se transmettent des messages que les threads. Suis-je paresseux / stupide / pressé? Oui, et nous le sommes aussi tous, à divers degrés.
user1172763

Réponses:

19

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.

Steven Evers
la source
2
J'appuie cette réponse. Les gens pensent que c'est difficile. Mais ce n'est pas quand vous passez suffisamment de temps à essayer de comprendre.
11
@Pierre, je m'attendrais à ce que beaucoup de gens définissent le dur comme "il faut passer assez de temps à essayer de comprendre".
Benjol
1
Le filetage devient beaucoup plus facile avec TPL et await/ asyncmots - clés :)
Rachel
@Pierre 303: Quand vous passez assez de temps pour comprendre, c'est toujours difficile , et en fait, les personnes qui le comprennent le mieux sont les plus susceptibles de l'éviter autant que possible.
Michael Borgwardt
9

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.

davidk01
la source
Note à soi: écrire des algorithmes parallèles ... merci.
Droogans
Files d'attente de messages (comme dans MFC). Cependant, faire en sorte que les programmeurs ne sabotent pas la file d'attente de messages (en partageant directement les données en mémoire), même lorsqu'il s'agit d'une infraction pouvant être déclenchée, semble avoir échoué.
rwong
3

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.

Josh K
la source
Pour mémoire, Mac OS ne vous permettra pas (lors d'une installation par défaut) de créer plus de 512 threads.
zneak
1
Cela dépend vraiment de votre langue. La génération d'un million de threads dans Erlang est à peine perceptible, même sur un ordinateur portable plus ancien, sans parler d'un serveur moderne. Et en fait, ce ne sont même pas des threads, ce sont des processus à part entière , c'est-à-dire beaucoup plus lourds que les threads. En plus de leur propre compteur de programmes et de leur propre pile d'appels (qui sont à peu près les seules choses qu'un thread possède), ils ont également leur propre tas et même leur propre garbage collector.
Jörg W Mittag
4
@ Jörg W Mittag: Je suis confus par votre commentaire. Comment erlang change-t-il la façon dont le système d'exploitation crée un thread ou un processus?
Steven Evers
1
@SnOrfus: Erlang n'utilise pas de threads OS. Il existe actuellement trois implémentations principales d'Erlang: BEAM, HiPE et Erjang. BEAM et HiPE sont des implémentations natives (qui peuvent même fonctionner sans aucun système d'exploitation) et implémentent leurs propres processus. Erjang s'exécute sur la JVM et implémente des processus utilisant la bibliothèque Kilim incroyablement brillante.
Jörg W Mittag
@ Jörg W Mittag: Compte tenu de ma question programmers.stackexchange.com/questions/28453/… , je trouve cela très intéressant. Je vous remercie.
Steven Evers
1

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.

Kamil Szot
la source
Bugs non corrigés? Je n'en ai jamais vu auparavant ..
adamk
Vous n'avez vraiment jamais vu de bug que vous ne pouviez pas corriger? Dans le temps et pour le salaire qui était disponible?
Kamil Szot
Si vous n'avez jamais rencontré de bogue non réparable, vous n'êtes pas dans l'industrie depuis assez longtemps. Au cours de mes 12 années de travail, chaque projet que j'ai jamais vu a au moins un bogue que personne n'a corrigé et personne ne sait comment le corriger ou même le reproduire. Cela inclut le code sur lequel j'ai travaillé et le code que j'ai accès à la lecture (code open source). Les seuls logiciels sans bogue sont ceux de moins de 2 ou 3 pages. Mais faire toutes vos pages de code 1 ou 2 ne résout rien du tout, car vous avez alors des bogues d'intégration.
slebetman
1

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

Manoj R
la source
Sont-ils censés être vrais ou faux? L'OP a demandé ce qui n'était pas vrai et effrayait les gens de la programmation multi-thread.
Steven Evers
en fait, vous n'avez pas besoin de verrous ou de synchronisation. Il existe également des modèles de transmission de messages (par exemple erlang, scala) et des modèles STM (par exemple clojure). Et en plus de cela, il existe des structures de données thread-safe qui n'ont pas besoin de verrous (ConcurrentHashMap en java) et des primitives atomiques qui ne nécessitent pas de verrous.
Kevin
1

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.

cmcginty
la source
Pouvez-vous recommander des ressources sur la façon de faire correctement les discussions?
Jonathan
Je suis sûr que cela a été résolu. Essayez de commencer ici stackoverflow.com/questions/660621/threading-best-practices
cmcginty
Le problème avec cela est que même si vous avez une couverture de test à 100%, vous n'aurez aucun moyen de savoir si vos tests couvriront tous les problèmes possibles avec la façon dont les instructions s'entrelacent avec les ressources partagées. D'un autre côté, avec une architecture de partage rien, cela devient beaucoup plus facile.
Zachary K
1

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.

Aucune chance
la source
1
Votre premier point me rappelle les erreurs de l'informatique distribuée ( en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ). Un grand nombre d'utilisateurs peuvent commencer à cliquer follement lorsqu'ils doivent attendre plus de 1 ou 2 secondes de votre point 2 pour une interface qui ne répond pas, ce qui aggrave les choses.
Sécurisé le
@Secure, le lien est intéressant, merci de le partager. Je ne suis pas sûr que nous pourrions jamais capturer l'attention de l'utilisateur tout le temps sur l'interface ou même sur l'ensemble du travail de nos jours. Je suis d'accord avec vous que dans les sites de commerce électronique, vous ne voulez pas du tout que l'utilisateur s'en aille.
NoChance
Je ne parle pas de l'accent. Lorsque l'utilisateur clique sur un bouton et que l'interface se bloque simplement parce que la base de données est interrogée, sans réponse visuelle indiquant que quelque chose est en cours, certains utilisateurs essaient de cliquer à nouveau sur le bouton. Et encore. Essayez ensuite de cliquer sur d'autres boutons ou options. J'ai vu des administrateurs faire cela qui devraient mieux savoir.
Sécurisé le
Pire encore lorsque l'écran de résultat est d'abord dessiné, mais affiché vide. Je ne connais pas la plupart des versions actuelles, mais le résultat de la recherche dans les anciennes perspectives est un bon mauvais exemple. Lors du démarrage de la recherche, il affiche "L'ensemble de résultats est vide" ou quelque chose comme ça, pendant quelques secondes avec une grande base de recherche, affichant les premiers résultats lorsqu'ils sont trouvés. Si vous êtes trop impatient ou pressé, vous êtes déjà passé au dossier suivant, croyant qu'il n'y a rien.
Sécurisé le
1
@Secure, je vois votre point. Ce que vous décrivez ici montre un bon exemple d'une interface utilisateur incohérente. Ce que vous avez décrit se produit également lorsque vous recherchez des fichiers. Mais quelle est la réponse à cette question autre que de dire à l'utilisateur que la recherche a déjà commencé?
NoChance