PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Threading in Python (+QT)


rotalever
2008-04-19, 20:30:36
Ich hab mal gehört, das Threading in Python nicht so gut implementiert ist, was auch immer das heißt.. Stimmt das? Und wenn ja wieso?
Wie sieht es in Verbindung mit der Nutzung von pyQT (Python-Bindings für QT GUI Bibliothek) aus? QT hat ja auch Threadklassen. Soweit ich mich erinnern kann, stehen diese bei pyQT auf der selben Basis wie die "normalen" Threads bei Python. Also würden Probleme die bei Python-Thread auftreten, wenn es denn so ist, wohl auch dieselben Probleme verursachen, wenn man die QT-Threadklassen verwendet?

Im Endeffekt geht es für mich halt darum eine GUI-Applikation (inkl. OpenGL) zu schreiben, da braucht man eben jede menge Threads u.a. für OpenGL etc.

Gast
2008-04-20, 21:28:36
der python-interpreter ist nicht threadsafe. das hat zur folge, das in einem programm nur ein thread gleichzeitig pythoncode ausführen kann.

wenn du in den qt-threads keinen pythoncode ausführen willst, könnte es dir was bringen, diese zu nutzen.

rotalever
2008-04-20, 21:36:34
Das hört sich schlecht an. Ich würde in mehreren Threads Python-Code gleichzeitig ausführen wollen. Gibt es da irgendeine Lösung um Python-Code in einer QT-Anwendung parallel ausführen zu lassen und zwischen diesen parallelen Abläufen trotzdem zu kommunizieren (über das Signal,Slot-Framework von QT)?

Gast
2008-04-20, 22:00:22
Das hört sich schlecht an. Ich würde in mehreren Threads Python-Code gleichzeitig ausführen wollen. Gibt es da irgendeine Lösung um Python-Code in einer QT-Anwendung parallel ausführen zu lassen und zwischen diesen parallelen Abläufen trotzdem zu kommunizieren (über das Signal,Slot-Framework von QT)?
der python-interpreter unsterstützt es nicht. es kann also keine 2 threads geben, die gleichzeitig python-befehle ausführen. auf einer single-core cpu fällt das eher weniger ins gewicht, aber auf multi-core cpus wird man die teile die wirklich parallel ablaufen sollen, in c schreiben müssen.

rotalever
2008-04-20, 22:23:15
Wieso fällt das bei einer Single-Core CPU nicht ins Gewicht?
Wenn ich zwei Funktionen habe

def a ():
f = open ("a","a")
while 1: f.write ("a")
def b ():
f = open ("b","a")
while 1: f.write ("b")

Dann macht es doch wohl einen Unterschied ob ich sie "gleichzeitig" ablaufen lasse, oder nacheinander. Meiner Auffassung nach würde doch Funktion a sonst die ganze Zeit den Interpreter blockieren, weil sie nicht fertig wird.

rotalever
2008-04-22, 18:50:26
Ich glaube ich habe es jetzt verstanden, wie es gemeint war. Auch wenn der Interpreter nur einen Thread gleichzeitig bearbeiten kann, laufen die Threads trotzdem "parallel" ab, also in kurzen Abständen hintereinander. Dann macht auch das Argument sinn, warum es auf Multicores Nachteile bringen kann, bzw. warum jeweils nur ein Core genutzt werden kann.
Ich hab es jetzt einfach an diesem Beispiel getestet:

#!/usr/bin/python

import time
from PyQt4.QtCore import *
from PyQt4.QtGui import *


class Printer (QThread):

def __init__(self, output, parent = None):
QThread.__init__(self, parent)
self.exiting = False
self.output = output

def __del__(self):
self.exiting = True
self.wait()

def run (self):
while not self.exiting:
print "Thread", self.output
time.sleep (0.01)


print "Creating A"
threadA = Printer ("A")
print "Creating B"
threadB = Printer ("B")
threadA.start ()
threadB.start ()
time.sleep (0.1)
del (threadA)
del (threadB)
print "Finished"


Ausgabe, wie erwartet:

Creating A
Creating B
Thread A
Thread B
Thread A
Thread B
Thread A
Thread B
Thread A
Thread B
Thread A
Thread B
Thread A
Thread B
Thread A
Thread B
Finished

The_Invisible
2008-04-22, 20:18:34
interessant, also unterstützt python gar kein richtiges threading.

das würde mir bei manchem code einiges erklären :D

mfg

rotalever
2008-04-22, 20:24:01
interessant, also unterstützt python gar kein richtiges threading.

das würde mir bei manchem code einiges erklären :D

Naja, der Vergleich zeigt halt, dass es sich auf einem Single-Core so wie richtiges Threading verhält (was auch immer das heißt). Auf Multicore würde es dann aber keine Performance zuwächse geben, da der Interpreter anscheinend nur auf einem Core läuft.
Vielleicht kann man das umgehen, in dem man mehrere Prozesse macht, anstatt Threads. Wie es dann aber mit der Kommunikation unter diesen Aussieht bin ich mir nicht so sicher. Kenn mich mit sowas noch nicht so recht aus.
Für viele Anwendungen reicht aber dieses single-core Threading vollkommen aus.

Shink
2008-04-22, 21:06:01
Irgendwie enttäuscht mich das jetzt doch... Dachte immer die Python-Bibliotheken ("batteries included") wäre halbwegs vollständig.

Wobei man sich ja bei vielen Betriebssystemen mit Threads ohnehin wenig erspart gegenüber Prozessen und für "billige" Threads "Soft-Threads" wie in Python oft eine bessere Alternative sind aber das ist ein anderes Thema.

rotalever
2008-04-22, 21:15:36
Irgendwie enttäuscht mich das jetzt doch... Dachte immer die Python-Bibliotheken ("batteries included") wäre halbwegs vollständig.
Ist sie doch :confused: Solche Threads wie in meinem Beispiel kann man doch machen. Habe das jetzt nur mit QT programmiert, weil ich im Endeffekt sowieso QT-Threads brauche.

rotalever
2008-04-26, 21:50:54
Für einzelne Befehle müsste Python doch dann auch automatisch Thread-sicher sein oder?
Also z.B. sowas:

class config:
def __init__ (self):
self.a = 7
def setA (self):
tmp = self.a+3
tmp %= 100
self.a = tmp
def getA (self):
return self.a

Wenn ein Thread A modifiziert und ein anderer Thread auf A zugreift, dann kann es doch eigentlich nicht zu fehlern kommen. Oder kann es passieren, dass während die Operation self.a = tmp ausgeführt wird, getA () weder a noch tmp zurückliefert. Wenn dem nicht so ist, bräuchte man sich nicht mehr um irgendeine Absicherung kümmern. Wär durchaus praktisch.