prozess und thread

[kostonstyle]

hallo miteinander
habe eine Verständigungsfrage, prozess kann mehrere Thread verwalten und ohne Prozess kann ein Thread nicht existieren?

Gruss kostonstyle

[Leonidas]

prozess kann mehrere Thread verwalten und ohne Prozess kann ein Thread nicht existieren?

Ja, genau so ist das.

[Dav1d]

Aber Threads werden nicht gleichzeitig abgearbeitet sondern bei z.B. 2 Threads

Thread1
Thread2
Thread1
Thread2
Thread1
Thread2

also hinterheinander und nicht gleichzeitig!

[droptix]

Threads können auch gleichzeitig abgearbeitet werden (Multithreading), z.B. bei einem Doppelkernprozessor.

Python hat da allerdings einige Einschränkungen. Im Regelfall arbeitet der Python-Interpreter Threads hintereinander ab, auch wenn deine Systemumgebung theoretisch multithreading-fähig ist. Das liegt glaube ich u.a. mit am Garbage-Collector... Wie ich hörte kann man Python aber dazu bringen, Threads parallel abzuarbeiten, aber dabei wird Python "verbogen"...

[Leonidas]

Im Regelfall arbeitet der Python-Interpreter Threads hintereinander ab, auch wenn deine Systemumgebung theoretisch multithreading-fähig ist. Das liegt glaube ich u.a. mit am Garbage-Collector... Wie ich hörte kann man Python aber dazu bringen, Threads parallel abzuarbeiten, aber dabei wird Python "verbogen"...

Nein, das stimmt so nicht und verbogen wird nirgendwo etwas. CPython hat jedoch einen Global Interpreter Lock, der sicherstellt dass nur in einem Thread gleichzeitig Python-Code ausgeführt wird. C-Module können jedoch diesen Lock freigeben und gleichzeitig zu Python-Code laufen (übrigens tut auch ctypes genau das).

[droptix]

Ah, danke... Begriffsverwechselung... GIL (Global Interpreter Lock) war was ich suchte. Ich hatte die ganze Zeit GC im Kopf.

Hilft das eigentlich wirklich? Ich war immer der Meinung, dass wenn der Eltern-Prozess (python.exe) im "Single-Threading-Modus" (nennen wir es mal so) läuft -- also der GIL aktiv ist -- dann kann ein Kindprozess (z.B. Python C-Modul) das nicht einfach aufheben und wirklich parallel dazu verarbeiten (Multi-Threading).

Bzw. was sind Nachteile, wenn der GIL deaktiviert wird?

[cofi]

Bzw. was sind Nachteile, wenn der GIL deaktiviert wird?

Man sollte das nur tun, wenn man wirklich genau weiss, was man tut. Das Problem ist, dass CPython nicht threadsafe ist, daher der Lock.

[BlackJack]

@droptix: CPython ist so ausgelegt, dass nur ein Thread gleichzeitig Python-Objekte manipulieren sollte bzw. nur der Thread, der gerade das GIL hält. Wenn eine C-Erweiterung etwas tut, was nicht direkt mit den Python-Objektdaten zu tun hat, zum Beispiel wenn `numpy` auf der internen Repräsentation von seinen Array-Objekten arbeitet, kann es das GIL solange freigeben und dann können Python-Code, und vielleicht andere "C-Operationen" auch tatsächlich parallel laufen.

Das GIL gilt letztendlich nur für Python-Bytecode bei CPython. Bei Jython und IronPython gelten die Regeln, die von der jeweiligen virtuellen Maschine vorgegeben werden.

[droptix]

D.h. man kann den GIL deaktivieren, wenn man etwas tut, das nicht mit Python-Objekten zu tun hat, sprich wenn ein Python-C-Modul z.B. interne C-Funktionen durchläuft.

Wieso ist Python eigentlich nicht threadsafe? Ist das so schwierig zu programmieren? Der GIL verhindert im Prinzip ja, dass Python "echte" parallel laufende Threads ausführen und damit viel schneller laufen kann.

[BlackJack]

@droptix: Python *ist* "thread safe", dafür sorgt ja das GIL. Wenn man das loswerden wollte, müsste man die internen Datenstrukturen durch viele kleine Locks schützen, die ständig verwendet werden müssten. Das wurde schon einmal versucht, durch den Overhead wurden dann aber Programme mit nur einem Thread deutlich langsamer. Da die aber, auch in Zeiten von Mehrkernprozessoren, immer noch der Normalfall sind, denn es lässt sich ja bei weitem nicht jeder Algorithmus auf mehrere Threads verteilen, wurde das nicht weiterverfolgt. Guido ist offen für Lösungen, unter der Bedingung, dass normale, single threaded Programme dadurch nicht langsamer werden.

[sma]

Wieso ist Python eigentlich nicht threadsafe?

Durch den GIL ist es das zwangsweise.

Ist das so schwierig zu programmieren?

Ja.

Der GIL verhindert im Prinzip ja, dass Python "echte" parallel laufende Threads ausführen und damit viel schneller laufen kann.

Ja.

Theoretisch sollte es möglich sein, einen Python-Interpreter von Grund auf neu unter Berücksichtigung von Nebenläufigkeit zu bauen. Damit das Ergebnis effizient ist, müsste man aber wahrscheinlich auf einige Eigenschaften von Python verzichten. Vielleicht ist es dann gar nicht mehr Python. Hilfreich wäre z.B. wenn es weniger globale Variablen und Datenstrukturen gäbe. Also sollten möglich alle internen Datenstrukturen unveränderbar sein, was insbesondere mit dem Konzept, HashMaps für alles nutzen zu wollen, in Konflikt gerät.

Die Programmiersprache Clojure ist interessant im Hinblick auf ihre speziellen unveränderbaren Datenstrukturen und ihre thread-lokalen Variablen als Standardfall für globalen Zustand. Clojure ist speziell für Nebenläufigkeit entwickelt worden.

Übrigens, sowohl Jython als auch IronPython kennen keinen GIL. Wie z.B. Jython aber das Problem löst, dass zwei Threads nicht gleichzeitig eine HashMap verändern dürfen, weiß ich nicht. Ob die da immer die mit Locks versehenen thread-sicheren Varianten von Java benutzen? Dies wäre übrigens weniger schlimm, als das naiv in C zu programmieren, denn die JVM ist recht gut darin, unnötige Synchronisationen wegzuoptimieren.

Stefan