✔ Deadlock im CDialog

[CodeFatal]

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

while(1){
    Lock();
    //mach was
    UnLock();
    PostMessage(<zum CDialog>);
    Sleep(50);}
//Thread wird nie verlassen

CDialog:
- Zeigt Elemente an
- Reagiert auf Messages

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:

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:

AfxBeginThread(...);
UINT myThread(LPVOID pParam){...}

 

[deepthroat]

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]

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ß

 

[deepthroat]

Was siehst du im Debugger?

 

[CodeFatal]

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ß

 

[deepthroat]

Welche Threads laufen?

Wie sieht der Callstack aus?

Wie sieht der Code konkret aus wo du den Thread startest?

 

[Endurion]

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]

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.