Comment, le cas échéant, n'Processus Erlang carte de Threads du Noyau?

Question

Erlang est connu pour être capable de supporter de NOMBREUX processus légers; il peut le faire parce que ce ne sont pas des processus dans le sens traditionnel du terme, ou même des fils comme dans P-fils, mais le fils entièrement dans l'espace utilisateur.

Ce qui est bien et bon (fantastique, en fait). Mais comment alors Erlang threads s'exécutent en parallèle dans un multicœur/environnement multiprocesseur? Sûrement qu'ils ont en quelque sorte être mappés à des threads du noyau pour être exécuté sur des noyaux?

En supposant que c'est le cas, comment est-ce fait? De nombreux processus légers mappé à un seul thread du noyau?

Ou est-il un autre moyen de contourner ce problème?

Answer 1

La réponse dépend de la VM qui est utilisé:

1) non-SMP: Il y a un ordonnanceur (OS thread), qui exécute tous les processus Erlang, pris de la piscine de processus exécutables (c'est à dire ceux qui ne sont pas bloqués par ex. receive)

2) SMP: Il y a K les planificateurs (OS threads, K est généralement un certain nombre de cœurs de PROCESSEUR), qui exécute les processus Erlang du processus partagé de la file d'attente. C'est une simple file d'attente FIFO (avec des verrous pour permettre un accès simultané à partir de plusieurs threads OS).

3) SMP dans R13B et plus récente: Il y aura K planificateurs (comme avant), qui exécute processus Erlang de plusieurs files d'attente de traitement. Chaque planificateur a sa propre file d'attente, de sorte que le processus de migration logique à partir d'un algorithme à l'autre sera ajouté. Cette solution permet d'améliorer les performances en évitant les excès de blocage dans le processus partagé de la file d'attente.

Pour plus d'informations, consultez ce document préparé par Kenneth Lundin, Ericsson AB, pour Erlang Utilisateur de la Conférence de Stockholm, le 13 novembre 2008.

Answer 2

Je veux ammend les réponses précédentes.

Erlang, ou plutôt l'Erlang système d'exécution (erts), par défaut le nombre de planificateurs (OS threads) et le nombre de runqueues nombre d'éléments de traitement de votre plate-forme. C'est-processeurs ou threads matériels. Vous pouvez modifier ces paramètres lors de l'exécution à l'aide de:

erlang:system_flag(schedulers_online, NP) -> PrevNP

Le processus Erlang n'ont aucune affinité pour toutes les planificateurs encore. La logique d'équilibrage les processus entre les planificateurs suit deux règles. 1) Une affamée planificateur de voler le travail d'un autre programmateur. 2) les voies de la Migration sont le programme d'installation pour pousser processus de planificateurs avec beaucoup de processus de planificateurs avec moins de travail. Ceci est fait pour assurer l'équité dans la réduction count (temps d'exécution) pour chaque processus.

Les planificateurs peuvent cependant être verrouillé à certains éléments de traitement. Ce n'est pas fait par défaut. Laisser erts ne le planificateur->core affinité utilisation:

erlang:system_flag(scheduler_bind_type, default_bind) -> PrevBind

Plusieurs autres lier les types peuvent être trouvés dans la documentation. À l'aide d'affinité peut grandement améliorer les performances de l'lourde charge les situations! En particulier, dans de verrouillage de situations de conflit. Aussi, le noyau linux ne peut pas gérer hyperthreads, pour dire le moins. Si vous avez des hyperthreads sur votre plate-forme, vous devriez vraiment utiliser cette fonctionnalité en erlang.

Answer 3

Je suis purement deviner ici, mais j'imagine qu'il y a un petit nombre de threads, qui pick processus à partir d'un processus commun de la piscine pour l'exécution. Une fois qu'un processus frappe une opération de blocage, le thread exécutant, il la met de côté et choisit une autre. Lorsqu'un processus exécuté provoque un autre processus pour devenir débloqué, qu'récemment débloqué processus est placé dans la piscine. Je suppose qu'un thread peut également arrêter l'exécution d'un processus, même quand elle n'est pas bloquée à certains points pour servir à d'autres processus.