WaitForSingleObject(m_SomeThread->m_hThread, INFINITE);
-
Hi Roger, Now I am uncertain if this was the problem Yuriy was having. I just read the entire thread again and noticed that in this post[^] Yuri states that "99% of cases the thread is already terminated, when the WaitForSingleObject() is called." :doh: I am starting to think there may have been a serious design flaw. I guess we should have asked to see some code. :) Anyway I am leaving the office soon. Have a good night, -David Delaune
Well, the OP's problem could still be the one we've been discussing. There is a possibility that the handled gets recycled between thread termination and the call to
::WaitForSingleObject(). When he claims that the thread is already terminated in 99% of the cases I doubt he really checks the return value; the wait may have failed since the handle has been closed but he doesn't care because it means that the thread doesn't run any longer. As I wrote earlier I still think he has introduced a race condition where the worker thread somehow sends a message to the main thread instead of posting. If the main thread has already assumed its waiting state on the thread handle the deadlock is a reality. This is in my opinion the most common reason for deadlocks when it comes to multithreading and would most definitely result in the behaviour he has described. It may be that he's calling a framework function that disguises the::SendMessage()call. The probability for a design flaw I guess is very close to 100%. I will have a good night; it's almost 1:00AM in Sweden and I'm about to hit the sack. I wish you a good night as well! -- Rog"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown