Multithreading
-
Ihr übertreibt ja voll. Das ist überhaupt gar nicht schwierig.
-
lolol schrieb:
Ihr übertreibt ja voll. Das ist überhaupt gar nicht schwierig.
Das glauben alle die es nicht verstanden haben.
-
lolol: Ist ein kleiner Junge, des nicht mal weis wie man Multithreading buchstabiert...
-
Danke für die vielen Antworten.
Habe mir schon das Buch "Inside Visual C++ 6.0" ausgeliehen und dort sind die Arbeitsthreads recht gut beschrieben. Zumindest weiß ich schon etwas übers Sync'n, finds echt gut die Threads über Ereignisse zu steuern. Jedoch finde ich es bissl umständlich für 1 Thread 2 CEvents hernehmen zu müssen, einer der den Thread startet und einer der ihn beendet. Aber was solls, danke an Gio für den Link, zwar kenn ich diesen MSDN Artikel schon aber vielleicht schaue ich nochmal genauer rein, hoffentlich finde ich diesesmal was. Weil mein Hauptproblem ist, ich weiß nicht, was ausgeführt wird, wenn ich die CreateThread() Methode aufrufe. Schließlich habe ich doch keine (Arbeits-)Funktion zugeordnet oder ähnliches.Liebe Grüße,
inva*edit*
Vielleicht kann mir jemand bei meinem Problem helfen:
Ich habe eine Arbeitsfunktion, bzw. möchte mir eine Implementieren, jedoch muss diese Funktion zwingend Methoden der Dialogklasse verwenden. Da die Arbeitsfunktion jedoch global und somit außerhalb der Klasse definiert&deklariert ist, bekomme ich hier Zugriffprobleme und ich habe gelesen das es gefährlich ist einfach den this Pointer in der AfxBeginThread Funktion zu übergeben. Jedoch habe ich davon gelesen, dass der Arbeitsthread Nachrichten an den Hauptthread senden kann, wozu er nur die Zugriffsnummer des Fensters brauch. Aber ich will ja nicht mit Hilfe dieser Zugriffsnummer den Hauptthread veranlassen seine Methoden zur Abarbeitung aufzurufen, dann bräucht ich keinen Arbeitsthread ... Den Code kopieren will ich auch nicht... Ich hoffe jemand von euch hat eine Idee bzw. einen Ansatz wie ichder Lösung meines Problems näher komme.
-
Wenn du CreateThread aufrufst wird der Thread Code ausgeführt.
CreateThread(NULL,0,&ThreadProc,this,0,&ThreadId);führt dazu das die Funktion
DWORD WINAPI TFormMain::ThreadProc(LPVOID lpParameter) { return(0); }ausgefürht wird. Wenn diese Funtion das return ausführt ist dein Thread auch wieder beendet. Das heißt mache eine while Schleife rein.
DWORD WINAPI TFormMain::ThreadProc(LPVOID lpParameter) { while(/*Event ThreadExit nicht gesetzt ist*/) { //Thread Code } //Ende Code //Event ThreadNotRunning setzen return(0); }
-
Naja, wenn Du deinen Thread mit AfxBeginThread startest musst Du Doch einen Funtionszeiger übergeben. Das ist deine Threadfuntion.
Bei CWinThread nehm ich InitInstance, mag aber sein, daß es da noch eine bessere Stelle gibt...;)Edit: da war schon jemand schneller

-
Danke maikhaenig, dass hat mir schonmal etwas weitergeholfen.
Jedoch habe ich in dem Code bzw. Programm, das ich Multithreading fähig machen will die Probleme, dass die Methoden der Klasse, eng an die Oberfläche gebunden sind und diese Zeitweise auch, über ein UpdateData(), aktualisieren wollen. Dies jedoch aus einem Arbeitsthread heraus nicht möglich ist.
Da fällt mir spontan ein, ich könnte doch mit Hilfe eine Nachricht aus dem Arbeitsthread heraus den Hauptthread veranlassen die Oberfläche zu aktualisieren, oder?
-
Es ist nicht gefährlich Methoden aus der Dialog Klasse zu verwenden!
Genauer:
- Es ist gefährlich und führt zu Problemen CWnd* aus einem anderen Thread zu verwenden.
- Es ist gefährlich zeitgleich auf Daten zuzugreifen, die zwei (mehrere) Threads gleichzeitig verwenden. Hier muss für eine Synchronisation gesorgt werden.
- Methoden sind nur Code. Solange keine Daten im Spiel sind, ist Code immer thread neutral.
- Es ist grundsätzlich zu überdenken ob Funktionen verwendet werden die Fenster bearbeiten oder Fenstern beeinflussen (SetWindowText etc.), wenn diese Fenster durch einen anderen Thread erzeugt werden. Dies führt zwangsläufig zu einer thread Synchronisation (was gewollt sein kann), oder zu einem Deadlock, wenn der Fenster-Thread keine Nachrichtenschleife ausführt.GUI & multithreading will sehr genau designed werden. Ansonsten bringt ein neuer Thread oft genug nichts.
-
du kommst an deine Metothen uber den Pointer LPVOID lpParameter
DWORD WINAPI Fensterklasse::ThreadProc(LPVOID lpParameter) { while(/*Event ThreadExit nicht gesetzt ist*/) { //Thread Code ((Fensterklasse *)lpParameter)->/*Funktionen oder Variablen*/; } //Ende Code //Event ThreadNotRunning setzen return(0); }Mit den Methoden die das Fenster verändern könnte es zu Problemen kommen.
Dann müßtest du die Message Methode verwenden. Oder das ubere eine Boolsche Variable die beide Threads kennen.z.b.: Hauptprogramm
if (IsNewData) UpdateData();Thread
((Fensterklasse *)lpParameter)->IsNewData=true;Diese Variable dann falls sie in beiden Threads beschrieben wird noch über eine CriticalSection schützen
MfG
-
Danke maikhaenig für den guten Ansatz, ich denke es wäre komfortabler einfach eine globale bool Variable zu nehmen, diese ist dann auch ohne Zeigerverdrehen auf beiden Seiten bekannt. Aber vielen Dank für den Tipp
