Thread mit form Synchronisieren ohne Synchronize



  • Hallo,

    wie kann ich einen Thread mit dem Formular Synchonisieren?

    HANDLE hThread;
    DWORD dwThreadID;
    bool Beenden;
    
    DWORD WINAPI ThreadFunc(LPVOID data)
    {
    	while(!Beenden)
    	{
    		Form2->Label1->Caption=wert; // Wie Synchonisier ich das??
    	};
    
    	return 0;
    }
    
    void __fastcall TForm2::Button14Click(TObject *Sender)
    {
    	Beenden=false;
    	hThread = CreateThread(NULL,0,ThreadFunc,0,0,&dwThreadID);
    }
    

    Bitte stellt mir nicht die Frage warum ich nicht das ThreadObjekt nehme... 🙂

    Hab ein wenig mit WaitforSingleObject herum gespielt, aber bin da zu keinem Ergebnis gekommen.

    Danke



  • Da gibt es mehrere Möglichkeiten, CriticalSection ist wohl die gebräuchlichste. WaitForXXXObject dient nicht zur Synchronisierung, sondern zur Steuerung mittels Events.

    Um bei deinem Beispiel zu bleiben, würde ich aber eher eine Nachricht an das Formular senden. Entweder blockierend (SendMessage) und einen Zeiger auf ein char-Objekt als Parameter übergeben, oder nicht blockierend (PostMessage), dann musst du aber eine CriticalSection, oder ähnliches verwenden, wenn du den Wert aus dem Thread liest.



  • Hallo

    Und du solltest gerade bei Threads auch keine globalen Variablen verwenden. In diesem Fall Form2. Sondern bei CreateThread den this-Zeiger als lpParameter übergeben und in der ThreadFunc aus data zurückcasten.

    bis bald
    akari



  • Joe_M. schrieb:

    Da gibt es mehrere Möglichkeiten, CriticalSection ist wohl die gebräuchlichste. WaitForXXXObject dient nicht zur Synchronisierung, sondern zur Steuerung mittels Events.

    Um bei deinem Beispiel zu bleiben, würde ich aber eher eine Nachricht an das Formular senden. Entweder blockierend (SendMessage) und einen Zeiger auf ein char-Objekt als Parameter übergeben, oder nicht blockierend (PostMessage), dann musst du aber eine CriticalSection, oder ähnliches verwenden, wenn du den Wert aus dem Thread liest.

    IIRC werden Nachrichten, die per SendMessage an ein Fenster gesendet werden, durch den Thread des Callers bearbeitet, womit die VCL wohl Schwierigkeiten haben wird. Bei der Verwendung von PostMessage stellt sich die Frage über die Lebensdauer des String Nachrichtenparameters.
    Die sauberste und flexibelste Lösung bietet mMn das Command Pattern in Verbindung mit einer Queue, das bedeutet aber einiges an Overhead (aber gleichzeitig auch Widerverwertbarkeit).

    Edit:

    MSDN schrieb:

    If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed.

    Wieder was gelernt 😉



  • Hmm... das hört sich nicht so an als ob das mit nem zweizeiler erledigt ist.

    Ich werd mal versuchen mich da rein zu denken. Bin aber immer für Beispiele Dankbar 😉



  • DocShoe schrieb:

    Bei der Verwendung von PostMessage stellt sich die Frage über die Lebensdauer des String Nachrichtenparameters.

    Ich hab nicht gesagt, dass er das bei PostMessage so machen soll ;), sondern nur, dass er eine Nachricht an das Form senden soll und dann mittels einer CriticalSection die Daten aus dem Thread lesen soll (was natürlich an dem Gültigkeitsproblem nicht viel ändert). Aber man könnte der Einfachheit halber die Queue im Thread belassen.

    DocShoe schrieb:

    Die sauberste und flexibelste Lösung bietet mMn das Command Pattern in Verbindung mit einer Queue, das bedeutet aber einiges an Overhead (aber gleichzeitig auch Widerverwertbarkeit).

    Sobald es etwas komplexer wird, läuft es wohl darauf hinaus...

    MSDN schrieb:

    If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed.

    Gut, dass ich SendMessage nirgendwo im Einsatz habe. Ich bin nämlich davon ausgegangen, dass der Thread an der Stelle wartet - und eben nichts anderes macht.


Anmelden zum Antworten