Deadlock im CDialog

CodeFatal

Erfahrenes Mitglied
Hallo,

ich habe ein nerviges Problem, bei dem ich wieder erwarten in einen Deadlock oder ähnliches verfalle.

Folgende Situation:
- MFC Dialogfeldbasierende App
- CriticalSection zum Locken wird verwendet

Thread 1:
- CS1
- Läuft (auch im Problemfall weiter)
- Hier nur der Vollständigkeit halber genannt
Code:
while(1){
    Lock();
    //mach was
    UnLock();
    PostMessage(<zum CDialog>);
    Sleep(50);}
//Thread wird nie verlassen

CDialog:
- Zeigt Elemente an
- Reagiert auf Messages
Code:
OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult){
if(Message == <Von Thread1>){
    Lock();
    //Mach was
    UnLock();
}}
- Bei einem Klick auf einen Button wird ein weiterer Thread gestartet

Thread 2:
Code:
while(1){//Nur zu Testzwecken um Deadlock zu finden
    Lock();
    //mach was
    UnLock();
Sleep(2000);//nur zu Testzwecken um Deadlock zu finden}
return;

Das ganze Spiel funktioniert solange, bis das Lock in der OnWndMsg(...) gerufen wird und Thread 2 schon im Lock ist.

Meine Frage: Warum geht das nicht weiter? Theoretisch sollte doch eigentlich der Thread 2 irgendwann durch sein und dann der Rest in OnWndMsg abgearbeitet werden.

Ich habe bereits eine ähnliche Frage gefunden. Leider hilft die mir nur nicht weiter.
Auch die Anleitung zu CriticalSection sind mir bekannt.

Wo übersehe ich was? Ist OnWndMsg(...) nicht asynchron zu meinem Thread?

Hoffe ihr könnt mir helfen.

Danke

P.S.: Ich rufe die Threads mit:
Code:
AfxBeginThread(...);
UINT myThread(LPVOID pParam){...}
 

deepthroat

Erfahrenes Mitglied
Hi.

Es wäre nicht schlecht wenn du mal etwas konkreten Code lieferst oder zumindest ansatzweise erklärst was die einzelnen Threads machen.

Ansonsten, bist du ganz sicher, dass // mach was in Thread 2 keine Endlosschleife ist? ;-]

Gruß
 

CodeFatal

Erfahrenes Mitglied
Guten Morgen,

was ich leider nicht geschrieben habe, ist das der Thread1 eine eigene Critical Section hat, sprich es sind nur Thread 2 und der CDialog gegeneinander verriegelt.

Von der Vollständigkeit des obigem Pseudocodes bin ich eigentlich überzeugt, da ich immer die gleichen Daten bearbeite.
Es wird in den jeweiligen Lock() UnLock() Bereichen eine CListCtrl bearbeitet.
Tritt der Fehler auf, bleibt das System mitten im gelockten Bereich stehen.

Kann das Problem darin bestehen, das ich im Thread die Membervariable des CListCtrl ändere und der Dialog im Lock verweilt?

Gruß
 

CodeFatal

Erfahrenes Mitglied
Der Läuft im Thread 2 ewig und drei Tage.
Breakpoint in OnWndMsg VOR Lock() kommt und ab Eintritt in die Lock ists vorbei.

Habe jetzt nochmal vor das Lock eine while(1)Sleep(400); geschrieben und die reicht schon aus um das System anzuhalten.

Das spricht aber dafür, das der Thread nicht wirklich eigenständig läuft.

Gruß
 

Endurion

Erfahrenes Mitglied
Wenn du innerhalb eines Windows-Message-Handlers was machst, blockierst du damit die Message-Pump dieses Threads. Alles, was irgendetwas mit einem Fenster in diesem Thread macht, wird blockiert.
 

CodeFatal

Erfahrenes Mitglied
Hallo,

wieder was gelernt. War ja schon meine Vermutung nur nicht bestätigt.
Habe jetzt alles in Threads ausgelagert und nu luppts.

Danke für die Hilfe.