wenn du den thread mit StopThread stoppst, weisst du den thread ja nur an, such selbst zu beenden.
Wenn du sichergehen willst, das der thread auch ausgelaufen ist ... musst du mit nem wait hinterher auf das beenden des threads warten ....
Das sympthom was du beschreibst passierst meisst, wenn der eine thread den anderen beendet, nicht richtig wartet bis er ausgelaufen ist, und dann trotzdem irgendwie ins aufrauemen laueft, wo der QThread und vor allem der Mutex geloescht wird. Dann kommt der eigentlich beendete thread noch mal zum zug und der "haengt noch" im Mutex ... der ja eigentlich gar nimemr existiert.
Code: Alles auswählen
void Processor::stopTheThread()
{
{
QMutexLocker l(&mutex); // <--- Absturz
serverOn = false;
}
/// warten bis der thread wiurklich zu ende ist ...
/// mit timeout der gross genug ist
if(wait(10000))
{
/// thread hat sich wieder erwarten doch ned selbst beendet
/// also die grobe Kelle auspacken
terminate();
/// und noch kurz was warten
msleep(100)
}
}
WIe gesagt, mach ned viel mit der QT bei Threads, aber so aehnlich sehen meine stopproceduren auch aus, abgesehen von serveron, das wird bei mir was anderes sein, meistens ne "Eventvariable".
der bool serveron mit nem mutex schuetzen iss fast overkill.
Ja er muss geschuetzt werden, oder man verwendet gleich atomics ...
die sind schneller und der mutex entfaellt, man laeuft ned aufn spinlock.
Nen mutex zu blocken und wieder freizugeben wird sicher viel mehr zeit beanspruchen als die variable zu schreiben ^^
Schau dir mal QAtomicInt an ....
Weiterhin:
while (ever)
{
...
processMessageFromQueue();
...
msleep(2);
Du pollst: Das ist meist die Mutter aller Probleme beim multithreading. (manchmal muss man es, aber man sollt es vermeiden wo es geht!)
processMessageFromQueue wer beschreibt die , bzw wer liefert die nachrichten da ein?
Kann der nich nen event setzen, wenn er nachrichten da reingepumpt hat ? Dann kommst vom pollen weg, und dein Programm wird ne menge performanter ....
Ciao ....
