M: N-Threading ist ein Modell, das M Benutzer-Threads abbildet auf N Kernel-Threads. Dies ermöglicht, dass eine große Anzahl (M) von Benutzer-Threads aufgrund ihres geringen Gewichts erzeugt wird, was noch (N-Wege-) Parallelität ermöglicht.
Das scheint mir eine Win-Win-Situation zu sein. Warum verwenden so wenige Sprachen / Implementierungen dieses Threading-Modell? Die einzigen Beispiele, die mir bekannt sind, sind Gos "Goroutines" und Erlangs Prozesse.
Was sind die Nachteile von M: N Threading? Warum verwenden andere Sprachen dieses Threading-Modell nicht, das oberflächlich so vielversprechend erscheint?
Teilweise ist es, weil "es das ist, was alle anderen machen". Während M: N-Threading vor Go existierte, verwendeten alle gängigen Sprachen (C, C ++, Perl, Java, C #, Python, Ruby, PHP) Threads und viele von ihnen (Python, Ruby) taten das schlecht. Go ist die erste bekannte Sprache, die zeigt, dass M: N-Threading gut funktionieren kann.
Teilweise liegt es daran, dass Threads das ursprüngliche Primitiv des Betriebssystems sind.
Das Implementieren von M: N-Threading macht Interop mit OS-code / C-Bibliotheken härter und etwas langsamer. Beim Aufruf von C / OS-Code muss Go vom kleinen Goroutine-Stack zum regulären OS-Stack wechseln.
Viele andere populäre Sprachen (Python, Ruby) verlassen sich stärker auf die Fähigkeit, C-Code als Go aufzurufen, daher ist es für sie wichtiger, dafür zu optimieren.
Gute M: N Threading Interop mit OS / C-Code ist nicht unmöglich (Go macht das anständig), aber es ist einfacher zu tun, wenn Sie tun, was OS tut.
Tags und Links language-agnostic multithreading programming-languages go erlang