Gibt es einen praktischen Unterschied zwischen Ruby vor 1.9 und Ruby 1.9 Threads?

Question

Gibt es einen praktischen Unterschied zwischen Ruby vor 1.9 und Ruby 1.9 Threads?

8

Ich versuche den Unterschied zwischen Ruby-Threads vor 1.9 und 1.9 (in der Standard-MRI-Implementierung) zu verstehen, aber es scheint, dass sie in Bezug auf die Vorteile, die Sie damit erzielen können, praktisch identisch sind. Ist das korrekt?

Von meinem begrenzten Verständnis:

Pre-1.9-Threads sind "grüne Threads", was bedeutet, dass sie vom Ruby-Interpreter und nicht vom Betriebssystem verwaltet werden. Eine Konsequenz daraus ist, dass Sie nie eine echte Parallelität erreichen, da Sie niemals mehrere Threads gleichzeitig ausführen lassen (selbst wenn Sie sich in einem Multicore / Multiprozessorsystem befinden). (Sie können jedoch die Darstellung der Parallelität erhalten, wenn die Ausführung zwischen verschiedenen Threads wechselt, z. B. wenn ein Programm ausgeführt wird, während ein anderes auf I / O wartet.)
1.9 Threads sind native Threads, was bedeutet, dass sie tatsächlich vom Betriebssystem verwaltet werden. Wenn es keine globale Interpretersperre gäbe, könnte Ruby mehrere Threads gleichzeitig ausführen (auf einem Multicore / Multiprozessorsystem). Aber Ruby hat eine globale Interpretersperre, was bedeutet, dass nur ein Thread jemals ausgeführt werden kann, so dass Sie wieder keine echte Parallelität erhalten. (Sie können jedoch immer noch den Eindruck von Parallelität erhalten, wenn die Ausführung zwischen verschiedenen Threads wechselt.)

Stimmt das, oder fehlt mir etwas? Was sind die Vorteile von 1.9 Threads im Vergleich zu vor 1.9 Threads (in MRI)?

ruby multithreading

grautur 21.06.2011, 02:50

quelle

3 Antworten

1

Ihre Analyse ist vollkommen korrekt, Ruby 1.9 verwendet jetzt nativen Thread, aber da es den Global Interpreter Lock gibt, bekommen Sie in Ihrem Ruby-Code wirklich nichts davon.

Es gibt bereits einige Arbeiten, um dies in anderen Implementierungen zu ändern:

JRuby hat bereits die GIL entfernt (ich bin mir nicht sicher, ob es anfangs eine GIL gab), aber die Implementierung ist nicht zu 100% kompatibel mit MRI, hauptsächlich wegen der nativen Edelsteine, wenn Sie sie verwenden (JRuby nicht C-Erweiterungen zulassen)
Rubinius 2.0 wird die GIL loswerden und die Arbeit daran sollte nun fast abgeschlossen sein: Eine Vorabversion wird bereits getestet und funktioniert schon ziemlich gut.

Edit: Ruby 1.9 aber hinzugefügt Faser, die eine nette Alternative in bestimmten Fällen sein kann, sie sind wie Thread, aber Sie sind derjenige, der sie plant.

Edit2: rubinius news auf Entwicklerversion 2.0: Ссылка

Schmurfy 22.06.2011 11:47

quelle

0

Unter 1.9 kann ein Thread I / O ausführen, während ein anderer Thread lautet CPU-Arbeit erledigen .

Ich habe eine verbreitete Fehleinschätzung gehört, dass Ruby blockiert von Natur aus "Blöcke" Disk IO oder Datenbankabfragen machen. Im Realität wechselt Ruby zu einem anderen thread wann immer es blockieren muss IO. Mit anderen Worten, wenn ein Thread benötigt zu warten, aber keine CPU verwendet, Die integrierten Methoden von Ruby erlauben ein anderes wartender Thread, um die CPU während zu verwenden Der ursprüngliche Thread wartet.

Was mir nicht viel hilft, da ich nicht an I / O gebunden bin, aber es könnte eine gute Nachricht für dich sein.

Andrew Grimm 22.06.2011 12:38

quelle

Tags und Links ruby multithreading

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Ziehen Sie Docker aus meiner privaten Docker-Registrierung, ohne den Host anzugeben

score 1 · Accepted Answer

Ich fühle mich irgendwie dumm, dies als Antwort anzubieten, aber Ihre Beschreibung passt perfekt zu meinem Verständnis der Situation.

Wenn wir Recht haben, sollte ich hinzufügen, dass es Sinn macht, die Sprache auf diese Weise zu entwickeln.

Beachten Sie, dass ein Hauptpunkt der funktionalen Programmierung Das Actor Model, und andere Shared-Memory-Alternative-Parallelmodelle sollen die extreme Schwierigkeit bei der Entwicklung einer parallelen Shared-Memory-Anwendung beheben. ("Threads, die als schädlich angesehen werden.")

Es hätte also viel zu viel erwartet, dass Ruby von nichts - parallel zu allem - parallel geht.

Der aktuelle Ansatz scheint darin zu bestehen, den Mechanismus einzurichten, aber das Riesenschloss zu halten. Ich gehe davon aus, dass in Zukunft individuell ausgeführte und getestete Funktionsbereiche parallel ausgeführt werden können, da sie genaueste Sperren und Gleichzeitigkeitsprüfungen erhalten.