Thread Deadlock Problem.
in [MFC]
|
Prev: "Problems"
Next: How well can TextOut() handle Unicode?
From: Keaven Pineau on 12 Feb 2010 15:37 Hello all, I did a dialog application with an utility class with 2 working threads in it that are calling callback functions of the xxxdlg class. Thead A is my main working thread. This thread his waiting on 2 events : 1- Quit Event 2- Optional callback call Event This thread is calling a callback function on every WaitForMultipleObjects() timeout, here 5000 ms. Thread B is an optional thread that can be enable/disable at anytime. This thread his waiting only a quit Event and when WaitForSingleObject() timeout it is setting the Optional Event of Thread A via SetEvent(). Timeout here is 15 000 ms. Each Thread are calling AfxEndThread(0,FALSE); at the end and the control function is waiting on A->m_hThread and/or B->m_hThread before deleting their respective object. Now, if I am not enabling thread B. I can start and end Thread A without any issue. If I start both thread A and B and I can also quit them without problem if they were both running. Now , If I start both thread A and B and stopping thread B and waiting a 10 seconds when I will try to stop thread A the WaitForSingleObject() on his handle will deadlock. I have found out that it is related with the event I am using for telling thread A to execute the optional callback. If I simply put the SetEvent() in comment, the problem never occurs. Any idea, why this is happening? Thank you
From: Alexander Grigoriev on 12 Feb 2010 22:45 Do you create the threads with m_bAutoDelete=FALSE? "Keaven Pineau" <keavenpineau-no-more-spam(a)videotron.ca-no-more-spam> wrote in message news:e2v2KMCrKHA.4492(a)TK2MSFTNGP05.phx.gbl... > Hello all, > I did a dialog application with an utility class with 2 working threads in > it that are calling callback functions of the xxxdlg class. > > Thead A is my main working thread. This thread his waiting on 2 events : > 1- Quit Event > 2- Optional callback call Event > > This thread is calling a callback function on every > WaitForMultipleObjects() timeout, here 5000 ms. > > Thread B is an optional thread that can be enable/disable at anytime. > This thread his waiting only a quit Event and when WaitForSingleObject() > timeout it is setting the Optional Event of Thread A via SetEvent(). > Timeout here is 15 000 ms. > > Each Thread are calling AfxEndThread(0,FALSE); at the end and the control > function is waiting on A->m_hThread and/or B->m_hThread before deleting > their respective object. > > Now, if I am not enabling thread B. I can start and end Thread A without > any issue. If I start both thread A and B and I can also quit them > without problem if they were both running. Now , If I start both thread A > and B and stopping thread B and waiting a 10 seconds when I will try to > stop thread A the WaitForSingleObject() on his handle will deadlock. > > I have found out that it is related with the event I am using for telling > thread A to execute the optional callback. If I simply put the SetEvent() > in comment, the problem never occurs. > > Any idea, why this is happening? > > Thank you
From: Joseph M. Newcomer on 12 Feb 2010 23:24 See below... On Fri, 12 Feb 2010 15:37:07 -0500, "Keaven Pineau" <keavenpineau-no-more-spam(a)videotron.ca-no-more-spam> wrote: >Hello all, >I did a dialog application with an utility class with 2 working threads in >it that are calling callback functions of the xxxdlg class. > >Thead A is my main working thread. This thread his waiting on 2 events : >1- Quit Event >2- Optional callback call Event > >This thread is calling a callback function on every WaitForMultipleObjects() >timeout, here 5000 ms. > >Thread B is an optional thread that can be enable/disable at anytime. This >thread his waiting only a quit Event and when WaitForSingleObject() timeout >it is setting the Optional Event of Thread A via SetEvent(). Timeout here >is 15 000 ms. **** Instead of giving an English explanation, why not show the code? It would help in the analysis. What you say it is doing and what it is really doing might differ, and I can't analyze a problem like this without seeing the code **** > >Each Thread are calling AfxEndThread(0,FALSE); at the end and the control >function is waiting on A->m_hThread and/or B->m_hThread before deleting >their respective object. **** ALWAYS consider the use of AfxEndThread as a coding error! You have NO IDEA what is going to get lost when you call that. NEVER use it. Under any conditions. There is exactly ONE correct way to terminate a thread, and that is returning from the top-level thread function. So you arrange your code so that is how you terminate the thread. I have no idea what is going to happen in your code if you call AfxEndThread, but it is reasonably safe to assume that it is nothing pleasant. You did not indicate if you have created your threads with the CREATE_SUSPENDED flag and set the m_bAutoDelete flag FALSE. You have not shown the code that does the wait. There is no possible way to do this analysis since all the crucial information (such as the code that does the thread creation and the WaitFors) is omitted from the description. **** > >Now, if I am not enabling thread B. I can start and end Thread A without >any issue. If I start both thread A and B and I can also quit them without >problem if they were both running. Now , If I start both thread A and B and >stopping thread B and waiting a 10 seconds when I will try to stop thread A >the WaitForSingleObject() on his handle will deadlock. **** Threads are not enabled. Threads are suspended, running, or blocked. And since there is no code shown, and no way to tell what sequencing is going on without it, no analysis can be performed. You have not indicated in any way if you set breakpoints, nor have you indicated where each of the threads is executing when you see this "deadlock". Why have you not supplied this utterly critical information? Do a Debug>Break All, then use the Debug>Threads to look at the call stack of each of the deadlocked threads; show the call stack for each thread, and when the thread is in your code, show the source code that is executing. Other than omitting everything required to do the analysis, there's nothing wrong with this question. **** > >I have found out that it is related with the event I am using for telling >thread A to execute the optional callback. If I simply put the SetEvent() >in comment, the problem never occurs. **** Callbacks are dangerous as a way of life, especially in C++. Try to avoid ever using them. The are an old C hack, rarely, if ever, valid in C++. **** > >Any idea, why this is happening? **** Show all relevant code and the stack backtraces when it hangs, and there's a chance someone could do an analysis. As the question stands right now, there's nothing more than vague and, as far as I'm concerned, only semi-coherent descriptions of what might be going on under some ill-defined set of circumstances. joe **** > >Thank you Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 13 Feb 2010 00:36 Its hard to determine what the problem is without some snippet of code to show what you are doing, especially when you have thread synchronization needs. One of the tricky parts of Thread design is making sure you are coupling the right pairs of Starting and Ending threads. Here it appears you are using CWinThread. For me, good thread design is having a complete design and understanding, when using a class like this, you are now subject to "design unknowns" and how things behave. A good study of the CWinThread source code will probably answer many/some of your questions. For example, your question is about the behavior related to SetEvent(), well, maybe understanding how the internal member event handles are created and under what initial state and signaling reset behavior will help. Here is what it has in the MFC\SRC\THRDCORE.CPP source code: startup.hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL); startup.hEvent2 = ::CreateEvent(NULL, TRUE, FALSE, NULL); They both have a bManualReset and a bInitialState setting of TRUE and FALSE, respectively. The question is; Does that make SENSE to you for your synchronization design logic and needs? Read what MSDN says about bManualReset parameter says about TRUE. If TRUE, then you must use the ResetEvent() function to manually reset the state to nonsignaled. Thats that make sense to you? One other thing, if your secondary threads don't need the "overhead" associated with CWinThread that I would consider going direct (CreateThread, or _BeginThreadEx) to have full control of the situation. -- HLS Keaven Pineau wrote: > Hello all, > I did a dialog application with an utility class with 2 working threads > in it that are calling callback functions of the xxxdlg class. > > Thead A is my main working thread. This thread his waiting on 2 events : > 1- Quit Event > 2- Optional callback call Event > > This thread is calling a callback function on every > WaitForMultipleObjects() timeout, here 5000 ms. > > Thread B is an optional thread that can be enable/disable at anytime. > This thread his waiting only a quit Event and when WaitForSingleObject() > timeout it is setting the Optional Event of Thread A via SetEvent(). > Timeout here is 15 000 ms. > > Each Thread are calling AfxEndThread(0,FALSE); at the end and the > control function is waiting on A->m_hThread and/or B->m_hThread before > deleting their respective object. > > Now, if I am not enabling thread B. I can start and end Thread A > without any issue. If I start both thread A and B and I can also quit > them without problem if they were both running. Now , If I start both > thread A and B and stopping thread B and waiting a 10 seconds when I > will try to stop thread A the WaitForSingleObject() on his handle will > deadlock. > > I have found out that it is related with the event I am using for > telling thread A to execute the optional callback. If I simply put the > SetEvent() in comment, the problem never occurs. > > Any idea, why this is happening? > > Thank you
From: Hector Santos on 13 Feb 2010 00:47
Joseph M. Newcomer wrote: > **** >> I have found out that it is related with the event I am using for telling >> thread A to execute the optional callback. If I simply put the SetEvent() >> in comment, the problem never occurs. > **** > Callbacks are dangerous as a way of life, especially in C++. Try to avoid ever using > them. The are an old C hack, rarely, if ever, valid in C++. -1. -- HLS |