Qthread für Anfänger

[marcel87]

Hallo,

ich setze mich gerade mit Qthread auseinander. Dazu nutze ich http://qt-project.org/, Google (darunter Maya Posch usw.) aber auch youtube. Ich komme dabei auf keinen grünen Zweig.

Kann mir bitte jemand erklären wie ich ein Qthread erstelle oder auch eine gute Website zusenden, die solch ein Problem behandelt und nicht veraltet ist. Ich möchte zunächst eine einfache Rechnung in einem Qthread ausführen, um Qthread besser zu verstehen.
Ich habe auch mir die Themen über Qthreads in diesem Forum durchgelesen, aber diese setzen ein Mindestverständnis vorraus, welches ich jedoch noch nicht habe und anzustreben versuche. Rein theoretisch verstehe ich, was nötig ist, um ein Qthread zum laufen zu bringen, aber ich schaffe es nicht umzusetzen.

Generelle Infos: Ich arbeite mit Qt 5.0.1, dabei setze ich die GUI ein.

[veeman]

Die einfachste Methode ist es ein QThread abzuleiten und die run-Methode zu überschreiben und dieses Objekt dann einfach mittels start auszuführen.

Code: Alles auswählen

class MyThread: public QThread
{
   protected:
              virtual void	run () {
                     for (int i=0; i<10; ++i)
                     {
                           qDebug() << "Thread message nr:" << i;
                           Sleep(1000);
                     }
              }
}

int main()
{
   ....
   MyThread r;
   r.start();
   while (r.isRunning())
   {
      qDebug() << "Waiting for thread";
      Sleep(250);
   }
}

Die Erklärung von Maya Posch geht da einen anderen Ansatz, da wird ein beliebiges Objekt einfach einem QThread zugeordnet (moveToThread) und
anschließend das start-SIGNAL mit einem SLOT des Objekts verknüpft um den Code des Objekts im anderen Thread laufen zu lassen wenn der Thread gestartet wird.

[RHBaum]

Generell wuerd ich nicht mit QThread anfangen.

QThread hat ein problem, es ist "bequem". Und versteckt eigentlich viele Grundlegende Themen ....


Konzeptionell ist das erzeugen von threads unter windows und Linux "ähnlich".
Die funktionen heissen bissi anders, aber die konzepte sind die selben.

es ist also "egal" ob dir die Windows API mit createThread anschaust, oder die Posix thread lib (libpthread) unter linux.

Wenn dann das Grobe verständniss dafuer hasst, was thread benutzen bedeutet, insbesondere:
"Warum darf eine Threadstartfunktion keine memberfunktion sein"
"wo werden stack(automatische) variablen angelegt, wenn man threads verwendet"
"wie uebergebe ich am besten parameter an einen thread, damit er weiss was er zu tun hat"
"wie fahre ich gezielt threads runter und stelle sicher das sie auch beendet wurden"

Dann wurd ich erst anfangen, comfortklassen fuer threads zu verwenden.
dann wuerd ich aber auch nicht gleich mit QThread anfangen, sondern mir erst mal std::thread ausm neuen standard anschauen.
wenn dann wiesst wie das funktioniert, insbesondere:
"wie mappt std::thread die threadstartfunktion auf eine Memberfunktion"
"wo werden welche variablen angelegt, aka zu welchen thread gehoern die nu eigentlich, aka muss ich sie schuetzen oder nich "

dann wuerd ich mich erst um QThread kuemmern.
Dort kommen dann noch paar klitzekleine Besonderheiten, konzepte hinzu ... aka:
- Threads + MessageQeueu's
- Movethread
- Probleme/DInge auf die man achten muss mit COW aka Impliziet shared typen

Wenn dann durch bist, ist gleich zu empfehlen mit dem Threadpool Konzept weiterzumachen ....

und dann bist Experte in Threading und nichts kann dich mehr ueberraschen

Das klingt jetzt viel, isses aber eigentlich nicht. Die Thematik ist eigentlich nicht so umfangreich, das Problem ist das verstaendniss ...
Du verlaesst das gebiet der synchronitaet, und gehst auf assynchrone ebene. Es ist das "denken in Threads" was schwerfällt, nicht die Grundlagen.

Wenn Du nicht wirklich Threads verstehst, und QThread einfach nach Kochbuch verwendest, dann wird das zwar in einfachen Fällen zu 80% erst mal laufen.
Aber sobald optimierst, oder komplexere Dinge brauchst, fällt alles über dich rein und du stehst Hilflos da ...

Ciao ....

[brax]

Ich stimme RHBaum zu, möchte aber anfügen, dass Du, wenn Du einen aktuellen Compiler benutzt, der C++11 unterstützt, die std::thread library benutzen solltest.

Außerdem würde ich wärmstens empfehlen statt selbst mit Threads und deren Synchronisierung usw. zu hantieren, Dir std::async und std::future oder Libraries wie OpenMP oder Threading Building Blocks anzugucken.

[RHBaum]

die std::thread library benutzen solltest

Kommt drauf an was er macht ...

Wenn er saubere Trennung zwischen logic und GUI hat, und auf logic ebene die threads recht wenig interaktion mit der GUI haben, geb ich Dir recht, ist std::thread IMHO auch die bessere Wahl.

Aber QThread hat auch nen Vorteil:
Es kann QT kompatible MessageLoops selber erzeugen, und mit dem assyncronen Connections lassen sich mit 1 Befehl threadwechsel bauen.
(man ruft dann aber meisten QThread nicht mit run, sondern mit exec auf)
Das ist nen eklatanter Vorteil, wenn man ne tiefe verzahnung zwischen GUI und den Threads hat.
mit std::thread waer da viel viel mehr Handarbeit notwendig.


Bau mal ne App die 20 assynchrone downloads managed, also auch den "Progress" jedes einzelnen Downloads in ner Progressanzeige darstellt.
Stell dir das mit std::thread vor und einmal mit QThread und signal/Slots
Dann weisst was ich mein ^^

Ciao ...

[marcel87]

Hallo!

Danke für eure Anworten! Ich gebe euch recht, dass man sich mit Threads generell auseinander setzen muss, um einen gescheiten Umgang mit Threads zu erlangen. Irgendwo muss ich trotzdem aber anfangen. Theoretisches Material besitze ich, aber man muss auch dieses umsetzen können. Die Antwort von veeman nützt mir soweit, dass ich erstmal ein Qthread am laufen habe. Dieses Prinzip hab ich aber weiterverfolgt, jetzt mache ich dieses "move to thread", welches ich vorhin nicht zum laufen bekam. Da Qthread bei mir läuft, muss ich mich damit weiter auseinandersetzen.

Was ich mit dem Qthread vorhabe: Meine GUI und Qthread sollen voneinander getrennt sein. Also Qthread soll rechnen (Logik) und das Ergebnis an meine GUI schicken. In der GUI an sich erfolgt keine Berechnung, sondern die Abarbeitung der Ergebnisse.

Danke nochmals für eure konstruktiven Tipps!

[RHBaum]

Meine GUI und Qthread sollen voneinander getrennt sein.

sondern die Abarbeitung der Ergebnisse.

Spricht eigentlich eher gegen QThread ....

"Normal" im Sinne von groesseren Projekten geht man eigentlich so vor:

Wechsel von "Synchroner Schnittstelle" auf "Asynchrone Jobbasierte Schnittstelle".

Also vorher war es meinetwegen snychron:

- berechnung starten
- berechnung wird durchgefuehrt
- berechnung fertig
- ergebnis wird weitervwendet

wird nun assynchron "aufgebohrt":

Mainthread:
- Berechnungs-Job wird erstellt und configuriert
- Berechnungs-Job wird dem Automaten/Queue zur ausführung uebergeben.
- rueckkehr zu anderen aufgaben

- Benachrichtigung das Job fertig ist
- Mainthread wird aus seinem normalen lauf rausgeholt (meist ueber messageQueues)
- Ergebnis liegt irgendwo beim Job/bei bzw es gibt da nen verweis
- ergebnis wird der abgeholt und weiterverarbeit
- rueckkehr zu anderen aufgaben

Diese Schnittstelle kannst auch komplett ohne multithreading bauen und testen .... die GUI wird dann nur etwas stocken ^^ trotzdem gut zur vorbereitung.
Multithreading ist dann ein implementierungsdetail ...
Wenn du auf Performance setzt / angewiesen bist, kommst auch ganz schnell von puren Threads weg hin zu Jobs + Threadpools
weil auf nem 8 kerner ists besser 8 Teilaufgaben vollstaendig auf 8 threads zu ende laufen zu lassen, als 96 threads gleichzeitig aufzuziehen und der scheduler switcht die staendig durch.
Ansonsten kommst schnell zum punkt wo dich die threadwechsel mehr kosten als das gesamte multithreading bringt.

Ciao ....

[marcel87]

Hallo RHBaum!

Ich bin zwar ein Anfänger in Bezug auf Threads, aber ich benötige für mein Programm ein Thread. Mir ist natürlich bewusst, dass es auch andere Lösungswege gibt. Die Frage ist dann nur: Will man sich selbst verwirklichen oder ein gut funktionierendes Programm schreiben? (Es kann ja auch sein, dass beides korrelliert.)
Das Stocken der GUI kann ich nicht gebrauchen. Trotzdem danke, ich merke mir Deinen Vorschlag. Man weiß ja nie, was man doch noch in der Zukunft gebrauchen könnte .

[RHBaum]

Oh sorry dann hab ich falsch angenommen, dass mehrere Berechnungen aka Threads haettest.
Für nur einen thread ist das natuerlich overhaed ...

Und klar Aufwand vs. Nutzen.
Wennn Performance nicht so vordergruendig ist, sondern nur die unterbrechungsfreie bedienung der GUI, dann sollt man sich schon ne menge an aufwand sparen ...

Ciao ...