I just found a major multithread bug a program I working on. First, I will describe the process that is causes the major multithread problem.
- user opens a text file (any size) w/ text only
- user clicks an option in the menu
- view has a executes its message handler for the menu item
- view calls a function in doc
- doc begins a new thread (thread includes CSinglelock + CriticalSection, data from doc)
- thread resumes and begins processing the data
- when done, thread *PostMessage* mainframe that is done ::: -> AfxGetMainWnd->PostMessage(WM_USER_THREAD, 0, 0);
- main frame *SendMessage* to view ::: -> pView->SendMessage(WM_USER_THREAD, 0, 0)
- view calls a function in doc to close thread
- doc class this function
// This function is called to close a thread
m_bThread = true; // meaning thread is still active
if (m_pThread && m_hThread) // m_hThread is a HANDLE to the thread
m_pThread = NULL;
m_hThread = NULL;
m_bThread = false; // meaning thread has been closed
Okay. Everything works good *if the use does not click anything* during the process. In other words, if the user were to click the menu or anything inside the window, the program would malfunction.
Notice the bool "m_bThread." I use it as an indicator about the status of the thread. if m_bThread is true, meaning that the thread is active, the program disables many options in the menu. These options will remain disabled unless m_nThread is false. For some reason, that variable remains *true* if the user starts clicks anyone in the menu or view processing. That means something is keeping the program to ever setting m_Thread to false. On the other hand, if the user does not click anything until after the process is over, everything works as planned.
I have no idea what is going on in the background. Is there a design flaw anywhere?