Wie werden Erlang-Prozesse, wenn überhaupt, Kernel-Threads zugeordnet?

Question

Erlang ist dafür bekannt, VIELE leichte Prozesse zu unterstützen; es kann dies tun, weil dies keine Prozesse im herkömmlichen Sinn sind, oder gar Threads wie in P-Threads, sondern Threads vollständig im Benutzerraum.

Das ist gut und gut (eigentlich fantastisch). Aber wie werden Erlang-Threads parallel in einer Multicore/Multiprozessor-Umgebung ausgeführt? Sicherlich müssen sie irgendwie Kernel-Threads zugeordnet werden, um auf separaten Kernen ausgeführt zu werden?

Angenommen, das ist der Fall, wie wird das gemacht? Sind viele Lightweight-Prozesse einem einzelnen Kernel-Thread zugeordnet?

Oder gibt es einen anderen Weg um dieses Problem zu umgehen?

Answer 1

Antwort hängt von der VM, die verwendet wird:

1) Nicht-SMP: Es gibt ein Scheduler (OS-Thread), die alle Erlang Prozesse ausführt, aus dem Pool von runnable Prozesse genommen (dh diejenigen, die beispielsweise durch receive nicht blockiert werden)

2) SMP: Es gibt K Disponenten (OS-Threads, ist K in der Regel eine Anzahl von CPU-Kern), der Erlang ausführt Prozesse aus der freigegebenen Prozesswarteschlange . Es ist eine einfache FIFO-Warteschlange (mit Sperren, um den gleichzeitigen Zugriff von mehreren Betriebssystem-Threads zu ermöglichen).

3) SMP in R13b und neueren: Es wird K Schedulern (wie vorher), die Prozesse von Erlang mehr Prozessen Warteschlangen ausführt. Jeder Scheduler verfügt über eine eigene Warteschlange, sodass der Prozess Migrationslogik von einem Scheduler zu einem anderen hinzugefügt wird. Diese Lösung verbessert die Leistung, indem eine übermäßige Sperrung in der gemeinsam genutzten Prozesswarteschlange vermieden wird.

Weitere Informationen this document von Kenneth Lundin, Ericsson AB vorbereitet sehen, für Erlang User Conference, Stockholm, 13. November 2008

Answer 2

Ich rate hier nur, aber ich könnte mir vorstellen, dass es eine kleine Anzahl von Threads gibt, die Prozesse aus einem gemeinsamen Prozesspool zur Ausführung auswählen. Sobald ein Prozess eine blockierende Operation erreicht, legt der ausführende Thread diese beiseite und wählt eine andere aus. Wenn ein Prozess, der gerade ausgeführt wird, dazu führt, dass ein anderer Prozess entsperrt wird, wird dieser neu entsperrte Prozess in den Pool platziert. Ich nehme an, ein Thread kann auch die Ausführung eines Prozesses stoppen, auch wenn es an bestimmten Punkten nicht blockiert ist, um anderen Prozessen zu dienen.

Answer 3

Ich möchte vorherigen Antworten auf ammend.

Erlang oder besser das Erlang-Laufzeitsystem (erts) setzt die Anzahl der Scheduler (Betriebssystem-Threads) und die Anzahl der Runqueues auf die Anzahl der Verarbeitungselemente auf Ihrer Plattform. Das sind Prozessorkerne oder Hardware-Threads. Sie können diese Einstellungen in Runtime ändern, indem Sie Folgendes verwenden:

erlang:system_flag(schedulers_online, NP) -> PrevNP 

Die Erlang-Prozesse haben noch keine Affinität zu Schedulern. Die Logik, die die Prozesse zwischen den Schedulern ausgleicht, folgt zwei Regeln. 1) Ein verhungernder Scheduler wird Arbeit von einem anderen Scheduler stehlen. 2) Migrationspfade werden eingerichtet, um Prozesse von Schedulern mit vielen Prozessen auf Scheduler mit weniger Arbeit zu schieben.Dies wird durchgeführt, um Fairness in der Reduktionszählung (Ausführungszeit) für jeden Prozess sicherzustellen.

Scheduler können jedoch für bestimmte Verarbeitungselemente gesperrt werden. Dies ist standardmäßig nicht möglich. Um die Scheduler-> Core-Affinität nutzen zu können, verwenden Sie:

Mehrere andere Bindungstypen finden Sie in der Dokumentation. Die Verwendung von Affinität kann die Leistung in Situationen mit hoher Last erheblich verbessern! Besonders in Konfliktsituationen mit hoher Sperrung. Auch der Linux-Kernel kann mit Hyperthreads nicht umgehen. Wenn Sie Hyperthreads auf Ihrer Plattform haben, sollten Sie diese Funktion wirklich in Erlang verwenden.

Answer 4

Ich möchte etwas hinzufügen, was in der angenommenen Antwort beschrieben wurde.

Erlang Scheduler ist der wesentliche Teil des Erlang Runtime Systems und bietet eine eigene Abstraktion und Implementierung der Konzeption von Leichtbau-Prozessen auf den OS-Threads.

Jeder Scheduler wird in einem einzelnen Betriebssystem-Thread ausgeführt. Normalerweise befinden sich so viele Scheduler wie die CPU (Kerne) auf der Hardware (sie ist jedoch konfigurierbar und bringt natürlich nicht viel Wert, wenn die Anzahl der Scheduler die der Hardware-Cores übersteigt). Das System kann auch so konfiguriert werden, dass der Scheduler nicht zwischen OS-Threads springt.

Wenn nun der Erlang-Prozess erstellt wird es vollständig in der Verantwortung des ERTS und Scheduler ist Lebenszyklus und Ressourcenverbrauch sowie dessen Speicherbedarf usw.

Eines der Kernimplementierungsdetails zu verwalten ist, dass Für jeden Prozess ist ein Zeitbudget von 2000 Reduzierungen verfügbar, wenn der Planer diesen Prozess aus der Ausführungswarteschlange abruft. Jeder Fortschritt im System (sogar I/O) garantiert ein Reduktionsbudget. Das macht ERTS zu einem System mit präemptivem Multitasking. Erlang Prozesse sind nicht OS-Threads und ordnen sie nicht direkt:

würde ich eine große Blog-Post zu diesem Thema von Jesper Andersen Louis http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html

Als kurzer Antwort empfehlen. Erlang Scheduler sind, was auf den Betriebssystem-Threads ausgeführt wird, und bieten eine intelligente Implementierung feingranularerer Erlang-Prozesse, die diese Details hinter den Augen des Programmierers verbergen.