Des processus, des fils, des fils verts, protothreads, les fibres, les coroutines: quelle est la différence?

Question

Je suis en train de lire sur la simultanéité. J'ai un peu plus de ma tête avec des termes très semblables définitions. À savoir:

• Les processus de
• Fils
• "Fils verts"
• Protothreads
• Les fibres
• Coroutines
• "Goroutines" dans le langage Go

Mon impression est que les distinctions reposent sur (1) si vraiment parallèles ou multiplexé; (2) qu'ils soient gérés par le CPU, à l'OS, ou dans le cadre du programme; et (3..5) quelques autres choses que je ne peux pas identifier.

Est-il un concis et sans ambiguïté guide pour les différences entre ces approches de parallélisme?

Answer 1

OK, je vais faire de mon mieux. Il y a des avertissements partout, mais je vais faire de mon mieux pour donner ma compréhension de ces termes et des références à quelque chose qui se rapproche de la définition que j'ai donné.

• Processus: OS-géré (peut-être) vraiment simultanées, au moins dans la présence de matériel adapté de soutien. Existent à l'intérieur de leur propre espace d'adressage.
• Thread: OS-géré, dans le même espace d'adressage, comme la société mère et toutes ses autres fils. Éventuellement vraiment simultanées, et multi-tâches est de préemption.
• Fil vert: ce sont l'espace utilisateur projections d'un même concept que les threads, mais ne sont pas des OS-géré. Probablement pas vraiment en concurrence, sauf dans le sens qu'il peut y avoir plusieurs threads ou processus en leur donnant le temps CPU simultanément, de manière sans doute préférable de considérer cela comme entrelacés ou multiplexé.
• Protothreads: je ne pouvais pas vraiment taquiner une définition de ces. Je pense qu'ils sont entrelacés et programme géré, mais ne prenez pas mon mot pour lui. Mon sentiment est qu'ils sont essentiellement une application spécifique à la mise en œuvre du même genre de "fils verts" modèle, une modification appropriée pour le domaine d'application.
• Fibres: OS-géré. Exactement fils, à l'exception de co-opératoire multitâche, et donc pas vraiment simultanées.
• Coroutines: Exactement fibres, sauf de ne pas l'OS géré.
• Goroutines: Ils prétendent être différent de tout autre chose, mais ils semblent être exactement fils verts, comme dans les processus gérés dans un même espace d'adresse et multiplexées sur le système de threads. Peut-être quelqu'un avec plus de connaissances de Go peut couper à travers le matériel de marketing.

Il est également intéressant de noter qu'il existe d'autres interprétations de la simultanéité de la théorie du "processus", dans le processus de calcul du sens. Cette définition est orthogonal à ceux ci-dessus, mais je pensais qu'il vaut la peine de mentionner, de sorte qu'aucune confusion se pose si vous voyez des processus utilisés dans ce sens quelque part.

Aussi, soyez conscient de la différence entre les parallèles et simultanées. Il est possible que vous utilisiez l'ancien dans votre question-là, je pense que tu voulais dire la dernière.

Answer 2

J'ai plutôt d'accord avec Gian réponse, mais j'ai des interprétations différentes d'un peu de simultanéité primitives. Notez que ces termes sont souvent utilisés de façon incohérente par les différents auteurs. Ces sont mes préférés définitions (j'espère ne pas trop loin de la moderne consensus).

• Processus:
  • OS-géré
  • Chacun a son propre espace d'adressage virtuel
  • Peut être interrompue (retardé) par le système pour permettre à un autre processus à exécuter
  • Peuvent fonctionner en parallèle avec d'autres processus sur différents processeurs
  • La surcharge de la mémoire de processus est élevé (comprend la mémoire virtuelle des tableaux, des descripteurs de fichiers ouverts, etc.)
  • La surcharge de temps pour la création et la commutation de contexte entre les processus est relativement élevé
• Fils:
  • OS-géré
  • Chacune est "contenue" dans certains processus particulier
  • Tous les threads d'un même processus partagent le même espace d'adressage virtuel
  • Peut être interrompu par le système pour permettre à un autre thread à exécuter
  • Peuvent s'exécuter en parallèle avec d'autres threads sur les processeurs différents
  • La mémoire et le temps frais généraux associés avec les threads sont plus petites que sur les processus, mais encore non négligeable
    • (Par exemple, typiquement, la commutation de contexte consiste à entrer dans le noyau et de l'invocation de la programmation du système.)
• Coopérative De Threads:
  • Peut ou peut ne pas être OS-géré
  • Chacune est "contenue" dans certains processus particulier
  • Dans certaines implémentations, chacun est "contenue" dans certains OS thread
  • Ne peut pas être interrompu par le système pour permettre à une coopérative entre pairs pour exécuter
    • (Le contenant processus/thread peut encore être interrompue, bien sûr)
  • Doit invoquer une spéciale de rendement primitif pour permettre à des pairs coopérative threads de s'exécuter
  • Généralement ne peut pas être exécuté en parallèle avec des pairs
    • (Bien que certains pensent que c'est possible: http://ocm.dreamhosters.com/.)
  • Il ya beaucoup de variations sur le thread coopératif thème qui portent différents noms:
    • Les fibres
    • Fils verts
    • Protothreads
    • Au niveau de l'utilisateur fils (au niveau de l'utilisateur threads peuvent être interruptable/préemptif, mais qui est relativement inhabituel combinaison)
  • Certaines implémentations de la coopérative de threads à utiliser des techniques comme le fractionnement/sectorielle des piles ou même individuellement tas-d'allouer à chaque appel, châssis pour réduire la surcharge de la mémoire associé à un pré-allouer une grande partie de la mémoire de la pile
  • En fonction de la mise en œuvre, en appelant un blocage syscall (comme la lecture à partir du réseau ou de dormir) sera à l'origine de tout un groupe de coopératives de threads pour bloquer ou implicitement en cause le thread appelant à rendement
• Coroutines:
  • Certaines personnes utilisent des "coroutine" et "coopérative thread" plus ou moins synonyme
    • Je ne préfère pas cette utilisation
  • Certains coroutine implémentations sont en fait des "superficielle" coopérative fils; le rendement ne peut être invoquée que par le "coroutine la procédure d'entrée"
  • Les eaux peu profondes (ou semi-coroutine) la version est plus facile à mettre en œuvre que les threads, parce que chaque coroutine n'a pas besoin d'une pile complète (juste une image pour la procédure de saisie)
  • Souvent coroutine des cadres de rendement primitives qui nécessitent l'invocateur explicitement état qui coroutine de contrôle doivent transférer à
• Générateurs:
  • Limité (peu de) coroutines
  • le rendement ne peut revenir en arrière quel que soit le code invoqué le générateur
• Goroutines:
  • Un étrange hybride de la coopérative et en OS threads
  • Ne peut pas être interrompu (comme coopérative de threads)
  • Peuvent s'exécuter en parallèle sur un language runtime-géré pool de threads OS
• Les gestionnaires d'événements:
  • Procédures/méthodes qui sont appelées par un événement dispatcher en réponse à une action qui se passe
  • Très populaire pour la programmation de l'interface utilisateur
  • Nécessitent peu ou pas de langage/système de soutien; peut être mis en œuvre dans une bibliothèque
  • Tout au plus un gestionnaire d'événements peut être exécutée à un moment donné; le répartiteur doit attendre d'un gestionnaire de finale (retour) avant de commencer le suivant
    • Permet la synchronisation relativement simple; autre gestionnaire d'exécutions ne se chevauchent dans le temps
  • La mise en œuvre de tâches complexes avec des gestionnaires d'événement tend à aboutir à une "inverted contrôle de flux"/pile"ripping"
• Tâches:
  • Unités de travail qui sont distribués par un gestionnaire à un bassin de travailleurs
  • Les travailleurs peuvent être threads, des procédés ou des machines
    • Bien sûr, le type de travailleur une tâche bibliothèque utilise a un impact significatif sur la façon dont on met en oeuvre les tâches
  • Dans cette liste de manière incohérente et de prêter à confusion, la terminologie utilisée, la "tâche" prend la couronne. En particulier dans les systèmes embarqués de la communauté, de la "tâche" est parfois utilisé pour signifier "processus", "fil" ou le "gestionnaire d'événement" (généralement appelé un "routine de service d'interruption"). Il est également parfois utilisé de façon générique/de manière informelle pour désigner tout type d'unité de calcul.

Une bête noire que je ne peux pas m'empêcher de diffusion: je n'aime pas l'utilisation de l'expression "vraie simultanéité" pour "processeur parallélisme". Il est assez commun, mais je pense que cela conduit à beaucoup de confusion.

Pour la plupart des applications, je pense que la tâche des cadres sont les meilleurs pour la parallélisation. La plupart de ceux populaire (Intel TBB, Apple PGCD, Microsoft TPL & PPL) utiliser des threads en tant que travailleurs. Je souhaite qu'il y en avait des bonnes alternatives à celle utilisée processus, mais je ne suis pas au courant de tout.

Si vous êtes intéressé par la concurrence (par opposition à un processeur de parallélisme), les gestionnaires d'événements sont le moyen le plus sûr d'aller. Coopérative les threads sont une alternative intéressante, mais un peu à l'ouest sauvage. S'il vous plaît ne pas utiliser des threads pour simultanéité si vous vous souciez de la fiabilité et de la robustesse de votre logiciel.