[gelöst]Frage zu QThread

Alles rund um die Programmierung mit Qt
Antworten
woody
Beiträge: 85
Registriert: 1. April 2011 21:13

[gelöst]Frage zu QThread

Beitrag von woody »

Hi kleine Frage zu QThread

Ich habe eine QWidget-Klasse(MyWidget), von der per Mouse-Click ein QThread gestartet werden kann, damit die Operation in einem eigenen Thread läuft und
den MainThread nicht blockiert.

Was passiert wenn jetzt innerhalb der run() Methode des Threads eine Methode (z.B methode zum holen von daten über einen datenmanager) der Klasse MyWidget aufgerufen wird. Passiert dann das Holen der Daten auch im Hintergrund?

Sicher oder? steh nämlich auf der Leitung?

danke für die hilfe
Zuletzt geändert von woody am 22. November 2011 15:04, insgesamt 1-mal geändert.
franzf
Beiträge: 3114
Registriert: 31. Mai 2006 11:15

Re: Frage zu QThread

Beitrag von franzf »

Passiert dann das Holen der Daten auch im Hintergrund?
Nicht "im Hintergrund", sondern in einem parallelen Ausführungsstrang - mit allen Problemen, die sich bei Zugriffen auf Daten/Resourcen aus unterschiedlichen Threads ergeben.
DU musst sicher stellen, dass Zugriffe gelockt werden (QMutex o.Ä.), sonst kann es ganz schön krachen.
Da Gui-Operationen nicht gelockt sind, sind Verändernde Zugriffe (label.setText(), model.addItem(), ...) nur aus dem Hauptthread heraus erlaubt, alles andere muss über SIGNAL/SLOT laufen.
Um gleich gar nicht in Versuchung zu kommen, übergib dem Thread keine Referenz auf das Widget/ui, sondern nur auf die Daten.
Lesende Zugriffe sind zwar gestattet, aber durch das Fehlen einer Absicherung unsicher.
RHBaum
Beiträge: 1436
Registriert: 17. Juni 2005 09:58

Re: Frage zu QThread

Beitrag von RHBaum »

alles andere muss über SIGNAL/SLOT laufen.
Um es genauer zu beschreiben, nen Signal/Slot aufruf aus deinem Thread raus, der nen Slot in dem Mainthread triggert, macht einen explizieten Threadwechsel -> queued connection.
Sprich dein Signal (Thread) stellt nen event in die MessageLoop, und wartet, bis irgendwann mal der mainthread das event und damit den verbunden slot, abgerabeitet hat, und laeuft erst dann weiter (blockiert so lange).
Da die Parameter per Kopie mit in die loop gestellt werden, macht das ganze auch threadtechnisch keine Probleme, wenn es sich bei den parametern nicht um Zeiger oder Referenzen handelt.

Du hasst also grob gesehen 2 Möglichkeiten (und ne Menge Varianzen :-) )
1. du uebergibst deinen Thread ne Referenz auf die daten, die der bearbeiten soll ... damit liegt die Verantwortung und threadsicherheit voll bei dir.
du musst die daten mit mutexen schuetzen und so weiter ....

2. du bestimmt wen, wer die Daten "haelt " meist der Meintrhead.
Der Arbeitthread holt sich dann nur Daten ab, bearbeitet die, und spult die zurueck, oder in nen neuen "Store" .. etc
Das einzig thread relevante ist dann das "abholen" und wieder "Zurueckspulen". Wenn das ueber Signale / Slots loest, macht die QT das threadgerödel fuer dich, und du brauchst dich um gar nix kümmern.
Aber die daten bei der übergabe und zurueck werden halt kopiert, das ist sicherer, aber oft langsamer. Meist ist der Geschwindigkeitsverlust aber irrelevant.

Ciao ...
solarix
Beiträge: 1133
Registriert: 7. Juni 2007 19:25

Re: Frage zu QThread

Beitrag von solarix »

RHBaum hat geschrieben: Sprich dein Signal (Thread) stellt nen event in die MessageLoop, und wartet, bis irgendwann mal der mainthread das event und damit den verbunden slot, abgerabeitet hat, und laeuft erst dann weiter (blockiert so lange).
Das Default-Verhalten (Qt::AutoConnection) ist "nicht-blockierend" (Qt::QueuedConnection).. nur bei der 'Qt::BlockingQueuedConnection' verhält sich Qt wie beschrieben.

Oder anders ausgedrückt: man kann sogar wählen, wie sich Qt verhalten soll :wink:
RHBaum
Beiträge: 1436
Registriert: 17. Juni 2005 09:58

Re: Frage zu QThread

Beitrag von RHBaum »

Stimmt, per default sind die Teile 100% assynchron.
woody
Beiträge: 85
Registriert: 1. April 2011 21:13

Re: Frage zu QThread

Beitrag von woody »

Danke für eure antworten, hat mir sehr geholfen!
Antworten