qtforum.de

Hallo,

nachdem ich mich mal an Multithreading versucht habe und mein Programm mir immer segmentation faults an den Kopf wirft, habe ich mich mal genauer mit Qt beschäftigt und komme mir eher blöder als vorher vor. Daher frage ich euch mal, ob ich alles richtig verstanden habe:

1. Die Event Loop: Wird aufgerufen über exec(), normalerweise in der run() Funktion. Ohne Event Loop kann ich keine Signale über QueuedConnection empfangen. Wenn ich mehrere Signale als QueuedConnection an eine Event Loop schicke, werden diese sequenziell abgearbeitet?

2. DirectConnection vs. QueuedConnection. Angenommen, ich schicke ein Signal von Thread A an Thread B. Weiterhin angenommen, ich wähle als Signaltyp DirectConnection, dann wird der zu B gehörige Slot unmittelbar in Thread A aufgerufen. Thread B läuft parallel dazu jedoch weiter, weshalb segmentation faults z.B. durch gleichzeitig genutzte Membervariablen entstehen können. Darüber hinaus ist es bei DirectConnections unerheblich ob eine Event Loop existiert oder nicht, da der Slot unabhängig davon aufgerufen wird.
Wenn ich nun eine QueuedConnection verwende, muss nur Thread B eine Event Loop besitzen.

3. Wenn ich den connect Befehl mit QueuedConnections verwende, sind diese der Grund, dass ich qRegisterMetatype verwenden muss. Da ich nicht sicher sein kann, dass der Slot unmittelbar nach dem Senden des Signals ausgeführt wird, müssen die übertragenen Daten irgendwo zwischengespeichert werden. Um Qt mitzuteilen, wie diese "aussehen", verwendet man qRegisterMetatype.

Wie schon gesagt, ein "stimmt" oder "stimmt nicht" ist völlig ausreichend. Falls alles stimmt, bin ich einerseits froh, dass ich es verstanden habe - auf der anderen Seite darf ich aber mein ganzen Programm wieder neu schreiben

Danke,

Thomas[/code]

nierth hat geschrieben: 1. Die Event Loop: Wird aufgerufen über exec(), normalerweise in der run() Funktion. Ohne Event Loop kann ich keine Signale über QueuedConnection empfangen. Wenn ich mehrere Signale als QueuedConnection an eine Event Loop schicke, werden diese sequenziell abgearbeitet?

Ja.

nierth hat geschrieben: 2. DirectConnection vs. QueuedConnection. Angenommen, ich schicke ein Signal von Thread A an Thread B. Weiterhin angenommen, ich wähle als Signaltyp DirectConnection, dann wird der zu B gehörige Slot unmittelbar in Thread A aufgerufen. Thread B läuft parallel dazu jedoch weiter, weshalb segmentation faults z.B. durch gleichzeitig genutzte Membervariablen entstehen können.

Ja. Genau... der Trick besteht darin, entweder den Zugriff (wie in herkömmlichen Threads) zu serialisieren (Mutex) oder gleich komplett auf direkte Aufrufe zu verzichten (mit der Queue-Strategie lassen sich die meisten Thread-Probleme wunderbar vermeiden).

nierth hat geschrieben: Darüber hinaus ist es bei DirectConnections unerheblich ob eine Event Loop existiert oder nicht, da der Slot unabhängig davon aufgerufen wird.

Ja.

nierth hat geschrieben: Wenn ich nun eine QueuedConnection verwende, muss nur Thread B eine Event Loop besitzen.

Ja.

nierth hat geschrieben: 3. Wenn ich den connect Befehl mit QueuedConnections verwende, sind diese der Grund, dass ich qRegisterMetatype verwenden muss. Da ich nicht sicher sein kann, dass der Slot unmittelbar nach dem Senden des Signals ausgeführt wird, müssen die übertragenen Daten irgendwo zwischengespeichert werden. Um Qt mitzuteilen, wie diese "aussehen", verwendet man qRegisterMetatype.

Genau.. es gibt zwar noch andere Anwendungen aber die "Queue" ist sicher eine davon.

nierth hat geschrieben:Falls alles stimmt, bin ich einerseits froh, dass ich es verstanden habe - auf der anderen Seite darf ich aber mein ganzen Programm wieder neu schreiben

Da bist du nicht der erste und auch nicht der letzte.
Nenn den Umbau einfach "Refactoring", dann fühlt sich das professioneller an

Vollständigkeitshalber noch drei Punkte:
- verifiziere den Kontext mit "qDebug() << QThread::currentThreadId();"
- Alle Antworten oben gelten nur bei korrektem "moveToThread(..)"..
- Es gibt noch einen anderen Weg für Threading, siehe http://labs.trolltech.com/blogs/2010/06 ... -it-wrong/

hth!

Dankeschön!