MFC application hangs in thread signaled for termination - c++

Question

I'm writing an app in MFC with a background worker thread (created via _beginthreadex) and UI thread. A button is clicked from the UI thread to begin and end the worker thread. It starts the background thread if the m_threadRunning flag is false, and stops the background thread if it is true. The way I go about stopping the thread is I set the m_threadRunning flag to false and call WaitForSingleObject to let the background thread finish what it is doing.
My app has four different states. I had the first three states working properly, and adding the fourth state is what caused my problem. For the fourth state I want to be able to sample the desktop and send average RGB values to the COM port for processing. When in any of the first three states, if I want to stop execution of sending data to the COM port, it will terminate normally and without problems. If I am in the fourth state and click "stop", the application will hang since I have no time out on my call to WaitForSingleObject.
I also have a custom CEdit box CColorEdit that shows the current RGB values. I update this from the background thread when I'm in either state 3 or 4 (since they both change the colors dynamically). I've narrowed down the problem to a call to when I'm setting the color in which I call either Invalidate or RedrawWindow.
I've come up with a few solutions, but I don't like any of them and would rather understand what is causing the problem since my goal in writing this in MFC is to learn and understand MFC. Here is what has resolved the problem:
I call Sleep() in my worker thread already at about 60 samples/second. Changing this to a lower value, like 30 samples/second, resolved the problem most of the time.
I poll m_threadRunning in my worker thread to check if the thread should be terminated. If I poll it after sampling the screen but before updating the edit control, this resolves the problem most of the time.
I do a timeout of 5 seconds when calling WaitForSingleObject and call TerminateThread to manually kill the thread when it fails to wait, this resolves the problem all of the time. This is my solution in place for now.
Here are the relevant code bits (I lock around any use of outBytes):
void CLightControlDlg::UpdateOutputLabel()
{
CSingleLock locker(&m_crit);
locker.Lock();
m_outLabel.SetColor(outBytes[1], outBytes[2], outBytes[3]); //the call to this freezes the program
CString str;
str.Format(L"R = %d; G = %d; B = %d;", outBytes[1], outBytes[2], outBytes[3]);
m_outLabel.SetWindowText(str);
}
This section of code is for terminating the worker thread
m_threadRunning = false;
locker.Unlock(); //release the lock...
//omitted re-enabling of some controls
//normally this is just WaitForSingleObject(m_threadHand, INFINITE);
if(WaitForSingleObject(m_threadHand, 5000) == WAIT_TIMEOUT)
{
MessageBox(L"There was an error cancelling the I/O operation to the COM port. Forcing a close.");
TerminateThread(m_threadHand, 0);
}
CloseHandle(m_threadHand);
CloseHandle(m_comPort);
m_threadHand = INVALID_HANDLE_VALUE;
m_comPort = INVALID_HANDLE_VALUE;
The code in my derived edit control that updates the text color:
void SetColor(byte r, byte g, byte b)
{
_r = r;
_g = g;
_b = b;
br.DeleteObject();
br.CreateSolidBrush(RGB(r,g,b));
Invalidate(); //RedrawWindow() freezes as well
}
And finally, the code for my thread procedure:
unsigned int __stdcall SendToComProc(void * param)
{
CLightControlDlg *dlg = (CLightControlDlg*)param;
while(1)
{
if(!dlg->IsThreadRunning())
break;
switch(dlg->GetCurrentState())
{
case TransitionColor: //state 3
dlg->DoTransition();
dlg->UpdateOutputLabel();
break;
case ScreenColor: //state 4
dlg->DoGetScreenAverages();
//if(!dlg->IsThreadRunning()) break; //second poll to IsThreadRunning()
dlg->UpdateOutputLabel();
break;
}
dlg->SendToCom();
Sleep(17); // Sleep for 1020 / 60 = 17 = ~60samples/sec
}
return 0;
}
Any help you can provide is greatly appreciated!

Answer 1

You get a deadlock when the worker thread attempts to access controls that were created in the main thread and the main thread is suspended in WaitForSingleObject. Updating controls from the worker thread can only proceed when the main thread accepts the associated message to the control.
Remove all accesses to the controls from the worker thread. Instead, PostMessage a custom message to a window in the main thread. An example is here:
http://vcfaq.mvps.org/mfc/12.htm
The same technique could be used to notify the main thread that the worker thread has completed, so you could avoid WaitForSingleObject.