Quelqu'un peut-il me suggérer un projet pour m'aider à comprendre le filetage

13

Je suis actuellement un développeur C # avec une compréhension assez fragile du threading.

Ces deux liens ont été suggérés dans d'autres articles:

http://www.yoda.arachsys.com/csharp/threads/

http://www.albahari.com/threading/

Dois-je revenir à l'essentiel et peut-être regarder quelques textes informatiques sur le sujet?

Je pense vraiment que si je me lance et que j'utilise les bibliothèques c #, je n'aurai pas vraiment une base solide de connaissances sur laquelle bâtir. Je pense que j'ai besoin d'apprendre ce sujet à partir de zéro comme un étudiant en science-fiction, puis d'utiliser les bibliothèques C #.

Quelqu'un peut-il suggérer une approche de l'apprentissage du filetage, peut-être des liens et / ou des idées de projet?

Merci d'avance!

Modifier, merci pour toutes les réponses. Certaines personnes ont mentionné qu'un livre pourrait être une bonne idée, quelqu'un peut-il en suggérer un? Je préférerais quelque chose de langue agnostique. Est-ce que quelqu'un sait dans quelle classe ces matières seraient couvertes par un diplôme en informatique? J'essaye de google pour quelques notes et devoirs en ligne gratuits.

c# computer-science multithreading

— bplus
source

Je ne sais pas si cela aide, mais c'est un didacticiel simple que j'ai écrit dans VB.Net il y a quelques instants qui explique le concept de base du filetage. Vous devriez pouvoir le convertir en C # assez facilement. chrishaas.wordpress.com/2009/06/25/…

— Chris Haas

Je suis fortement tenté de suggérer d'écrire une interface graphique multithread, au motif qu'elle enseignerait les limites de ce qu'il est possible de faire avec les threads et rester saine d'esprit. Mais ce ne serait pas constructif, alors je vais le laisser faire un commentaire, pas une réponse… :-)

— Donal Fellows

3

Écrivez un serveur Web multithread. Vous apprendrez une tonne . Et pas seulement sur le filetage.

— GrandmasterB
source

4

Le problème producteur-consommateur est un exemple classique, et il vous aide à comprendre non seulement le threading, mais la planification du processeur (il peut être démontré en utilisant fork () pour les processus enfants par opposition aux threads) et comment vos programmes interagissent avec le système d'exploitation derrière les scènes.

Voici un aperçu des choses importantes que vous devez comprendre en ce qui concerne le threading / forking 1. Comment le système d'exploitation planifie les tâches (algorithme de tourniquet par exemple) 2. Verrouillage des ressources (si plusieurs threads utilisent la même ressource, vous ne voulez pas qu'ils y accéder en même temps - BAD THINGS HAPPEN)

Voici un article wiki sur ce problème classique: http://en.wikipedia.org/wiki/Producer-consumer_problem

Fondamentalement, créez un "producteur" qui génère des fils de "consommateurs". Le producteur produit une «ressource» et les consommateurs la consomment. Mettez-le en boucle et regardez ce qui se passe (vous serez surpris que les consommateurs consomment finalement plus de ressources, puis sont disponibles en raison de méthodes non synchronisées).

Intéressant, semble avoir configuré ce modèle sans le réaliser lors de la création d'un service Windows fileté. Votre description était parfaite. Bon à savoir, cela serait presque marqué comme une réponse à ma question ouverte.

— Tony

2

Choisissez l'un des problèmes classiques hautement parallèles. Vous pourriez trouver plus intéressant d'en choisir un avec une accélération super-linéaire.

Envisagez de rechercher dans une liste non triée et non indexée. Ce problème est trivialement parallèle. Implémentez d'abord une recherche unique, puis une recherche parallèle naïve. Mettre en œuvre le vol de travail. Générez des ensembles de données aléatoires et exécutez les trois versions sur les mêmes ensembles de données. Calculez l'accélération.

— Ben Voigt
source

0

Je ne pense pas qu'un manuel soit la prochaine meilleure étape. Un projet est la voie à suivre. Cela devrait être quelque chose qui vous passionne.

La première fois que j'ai fait du filetage, j'améliorais les performances d'un robot d'exploration Web. Vous pouvez explorer beaucoup plus rapidement si vous ne faites pas toutes vos E / S réseau en série. C'est un excellent projet pour commencer, car vous pouvez l'aborder de plusieurs façons, mais ce n'est pas aussi compliqué que, par exemple, la programmation GUI multithread. Cela ne nécessite pas non plus beaucoup de compétences spécialisées (par exemple, des trucs informatiques lourds).

Alors, découvrez quelques informations à gratter et commencez à pirater. Il ne devrait pas vous falloir longtemps pour que quelque chose se passe, ce sera une douce introduction.

— Henri
source

Je suis d'accord avec un projet, mais les E / S réseau ne sont pas un bon cas d'utilisation pour les threads. Les E / S non bloquantes sont plus efficaces, utilisent moins de ressources et souffrent de moins de conditions de concurrence et de cas d'angle que le même problème résolu avec les threads. Une partie de l'apprentissage pour être un bon programmeur parallèle consiste à reconnaître quand les threads ne sont pas idéaux.

— Ben Voigt

Vous avez très bien raison, l'expérience à laquelle je faisais référence était un grattage Web Python très basique où j'ai ajouté environ 8 lignes de code pour le rendre multithread. Je doute qu'il aurait été aussi simple de le faire en asynchronisation avec le code existant, mais j'aimerais savoir si / comment je me trompe. Je pense qu'une partie de l'apprentissage pour être un bon programmeur parallèle pourrait être d'avoir beaucoup d'expérience à son actif, bonne et mauvaise :)

— Henry

0

Modélisez une simple application Spy vs Spy.

Chaque espion s'exécute sur un thread distinct.

Chaque espion peut infliger des dégâts à l'autre espion, mais pas directement.

Chaque espion peut voler de précieuses ressources à l'autre espion, mais pas directement.

Les deux espions disposent d'un bassin limité de ressources et doivent les partager. Un seul espion peut utiliser une ressource donnée à la fois.

— Mike Hofer
source

0

Du haut de ma tête: la 4e édition du livre de Bruce Eckel "Penser en Java" a un très long chapitre sur le filetage (> 100 pages - presque un petit livre en soi). J'ai lu des éditions plus anciennes du livre et je n'ai donc pas lu ce chapitre; mais je me souviens d'un de ses articles de blog (ou des notes de sortie de son livre), où il prétend que l'écriture a été très difficile et qu'en fin de compte, c'était une véritable réussite pour lui. Vérifiez-le...

En plus de cela, il y a ce cours vidéo de 2,5 heures sur ce site de formation commerciale, mais vous pouvez obtenir un essai gratuit (vous devez laisser les données de votre carte de crédit, alors n'oubliez pas de vous désinscrire)

http://www.pluralsight-training.net/microsoft/olt/Course/Toc.aspx?n=clr-threading

— knb
source

0

Dois-je revenir à l'essentiel et peut-être regarder quelques textes informatiques sur le sujet?

C'est toujours un bon choix et je vous recommande de prendre un bon livre de filetage afin de vous familiariser avec le filetage. J'ai appris le multithreading en Java et les connaissances se traduisent assez facilement en C #.

Si vous voulez un exemple pratique, je vous recommande d'essayer le problème du philosophe de la salle à manger .

Vous devez apprendre plusieurs choses lorsque vous vous lancez dans le multithreading:

Les différentes façons de synchroniser (sémaphore, mutex, etc.)
Opérations atomiques (en C #, cela se fait via Interlocked pour les opérations qui ne sont pas atomiques par défaut).
Programmation simultanée sans verrouillage.
Programmation simultanée sans attente.
Threads, ThreadPools, BackgroundWorkers, etc.

Je ne peux pas penser à autre chose pour le moment. Le tutoriel Albahari a l'air vraiment bien!

— Kiril
source

Malheureusement, manger des philosophes n'est pas un problème utile. Il est destiné à être une démonstration des conditions de concurrence, mais si le blocage se produit réellement est soumis aux caprices du planificateur du système, à d'autres tâches, aux interruptions matérielles ... bref, c'est complètement indéterministe, et je pense que ce n'est pas un bon endroit pour Commencer à apprendre.

— Ben Voigt

1

@Ben Voigt, je conviens que le problème des philosophes de la restauration n'est pas déterministe, mais je dirais que la majorité des problèmes de threading ne sont pas non plus déterministes. Quand j'ai pris un cours de programmation simultanée, c'était l'un des premiers exercices que nous avons fait, maintenant je ne prétends pas que l'enseignant avait nécessairement raison, mais il était certainement l'un des meilleurs enseignants que j'ai eu et sa capacité à expliquer et enseigner la simultanéité était superbe. Le DPP ne présente qu'un seul type de problème de concurrence: le blocage. L'OP devrait également examiner les conditions de course, le problème ABA, etc.

— Kiril

@Lirik: Bien sûr, comprenez le problème des philosophes de la restauration. Mais je ne le mettrais pas en œuvre. Écrire un mauvais code peut devenir une habitude difficile à briser.

— Ben Voigt

@Ben Voigt, désolé, je dois manquer quelque chose: le but du problème des philosophes de la restauration est d'écrire un programme qui ne se bloque pas , alors comment résoudre le DPP nécessiterait-il l'écriture d'un "mauvais code"?

— Kiril