qtforum.de

Ich habe eine Calculatation desse Daten die die GUI bei bedarf auch dargestellt werden können sollen

void AlgorithmIFTA::Iteration()
{
	// *** Input -> FFT -> Output
	this->transToOutput();

	emit ValuesChangedOutput();
				
	// ******** ALGORITHM ******************************** 
	// *** Output -> iFFT -> Input
	this->transToInput();

	emit ValuesChangedInput();
}

Die Signal lösen im Mainthread ein Auslesen und Plotten der Arrays vom Rechnethread aus. Allerdings ist in der Zwischenzeit natürlich schon weitergerechnet worden und die Daten in den Arrays habe sich geändert.

Jetzt habe ich gesehen das Qt Klassen wie QMutex und ähnliche anbietet. Allerdings habe ich sehr wenig Ahnung von Threads und mir ist nicht klar ob QMutex mir in meinem Problem überhaupt etwas bringt und wie ich es implementieren sollte.

Mir würde jetz einfallen, dass ich vor dem emit ein locked = true setze und darauf warte das der GUI Thread nach dem Plotten wieder unlocked.

Eine Lösung für dieses Problem wurde dir schon mal von Sephral genannt. Warum benutzt du dieses Lösung nicht?

upsala hat geschrieben:Eine Lösung für dieses Problem wurde dir schon mal von Sephral genannt. Warum benutzt du dieses Lösung nicht?

Ich weiß nicht genau was du meinst. Das Threading ansich funktioniert perfekt. Auch die Kommunikation mit dem GUI Thread ist kein Problem. Meine Frage bezieht sich auf das Locking der Daten und das habe ich hier im Forum noch nie angesprochen.

Wen Du lockst ist der Sinn der Threads nicht mehr da - er muss warten bis die Daten wieder freigegeben werden (wenn das nur sehr kurz ist geht es natürlich auch). Ich würde die Daten einfach kopieren (wenn es nicht gerade zig MBs sind).

Hallo,

wie bereits mehrfach gesagt, einen worker-thread für eine GUI-Ausgabe zu blockieren macht wenig Sinn. Entweder kannst du damit leben dass eine Ausgabe / Visualisierung immer nur eine Momentaufnahme darstellt (Kopie des Datenbestandes erzeugen und zum Visualisieren an die GUI schicken) oder du baust eine Live-Visualisierung ein. Bei der Live-Visualisierung wirst du aber schnell an einen Punkt kommen an dem die Visualisierung aufwändiger wird als Deine ganzen Berechnungen im Hintergrund und Dein Programm dadurch ausgebremst wird.

Was du machst hängt letztendlich davon ab wie umfangreich Deine Daten sind und wie die use cases der Anwendung gestrickt sind.

Ciao,
Sephral

Wie gesagt, die meisten nutzen multithreading um sich das unterbrechen, und weider anfangen an der selben stelle, also das nur sekunden oder millisekunden weise abarbeiten einer laengeren berechnung zu sparen ....

weil da ist multithreading doch einfacher als obiges korrekt zu implementieren, nur um threading zu vermeiden und mit timern arbeiten zu koennen.

Geht es dir aber wirklich um performance, das deine berechnung ideal auf mehrere kerne aufgeteilt wird, etc ... ist die ganze sachen um welten komplexer ....
Um da zu begreifen und abzuschaetzen, was sinnvoll ist oder ned, muss man sich scho bissi mehr mit der materie beschaeftigen.
Und wenn wer fragt, ob nen QMutex "Sinn macht", egal in welchen zusammenhang, der iss noch weit davon entfernt.

Klingt jetzt boese, isses aber auch ....

Schnapp dir nen Buch, lern was ueber threads, prozesse, Mutexe, atomic operations ... etc .... wenn dir dass gelaufig ist, schau dir Bibls an, die dir da helfen (OpenMP z.b.) schau dir deine compiler genauer an, was der so kann und nicht kann ....

Wenn Dich dann damit auskennst, werden Dir viele deiner momentanen Fragen eh selber unsinnig vorkommen

Keiner behauptet das multithreading trivial ist

und keiner wird Dir hier in dem Forum die Grundlagen beibringen wollen / können.

Ciao ...

qtforum.de

Thread Locking

Thread Locking