C / C++ / MFC

29-Apr-02 17:49

Hi.

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
{
::WaitForSingleObject(m_hThread, INFINITE);
delete m_pThread;
m_pThread = NULL;
m_hThread = NULL;
m_bThread = false; // meaning thread has been closed

SetModifiedFlag(TRUE);
}

UpdateAllViews(NULL);
-----

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?

Thanks,
Kuphryn

Neville Franks30-Apr-02 2:15

30-Apr-02 2:15

kuphryn wrote:
::WaitForSingleObject(m_hThread, INFINITE);

This doesn't close a thread, it simple waits for thread to end. My guess is that you have deadlock occuring between your worker thread and the main app thread.

Does the thread function itself end? Is the thread doing any UI stuff?

Neville Franks, Author of ED for Windows. www.getsoft.com

valikac30-Apr-02 4:05

30-Apr-02 4:05

Thanks.

The worker thread communicates with the main thread (UI) on two occassions. It *SendMessage* main to update a progress bar. It *PostMessage* main, which *SendMessage* to view, which calls a function in doc to "close" the thread. When I said close, I am talking about the same function I originally posted above.

I still have no idea what is causing the program to not respond if the user starts click different part of the program. The only thing I can think of is that main ignores the message from the worker thread to close it.

Kuphryn

Neville Franks30-Apr-02 8:15

30-Apr-02 8:15

Using SendMessage from one thread to another is a very bad idea. Try either removing that or changing it to PostMessage and see if the problem is resolved.

I don't understand why the worker thread is asking the main thread to close it, but that is another issue entirely.

Neville Franks, Author of ED for Windows. www.getsoft.com

valikac30-Apr-02 11:44

30-Apr-02 11:44

Thanks.

First, the only time the worker thread *SendMessage* to main thread (UI) is to update the progress bar. Prosise's actually uses *SendMessage* in the image view program in his book. I wonder why he uses *SendMessage* for the progress bar and *PostMessage* after the worker thread closes.

I tried implementing *both* *PostMessage* and *SendMessage*. I ran into the exact same program.

Kuphryn

Neville Franks30-Apr-02 11:54

30-Apr-02 11:54

If your thread is a Worker Thread and not a UI Thread then it is safe to use SendMessage, but I still would use PostMessage. There is usually no reason why the thread should stop and wait for something to be processed in the main thread, which will happen if you use SendMessage.

Run your app under the Debugger and when you have the problem break into the debugger and look at each of threads and see what they are doing. You can select a Thread on the Debug menu and then look at its Stack Backtrace etc. This should help you to see where the problem is.

ED4W makes heavy use of threads and you can spend a lot of time sorting out multithreading problems, especially when you haven't done much multithreading before. Unfortunately MFC makes life more difficult than it needs to be for multithreaded apps.

There are lots of good articles around on Multithreading including some on this site if my memory serves me correctly.

Neville Franks, Author of ED for Windows. www.getsoft.com

valikac30-Apr-02 12:00

30-Apr-02 12:00

Thanks.

I have no experience using degugging tools such as Spy++, which a member mentioned at Anandtech, and the tool to monitor a specific thread in Visual C++.

Can you give me a quick walkthrough? I just need the order such as "1) select this 2) begin 3) look."

Kuphryn

Neville Franks30-Apr-02 12:30

30-Apr-02 12:30

kuphryn wrote:
I have no experience using degugging tools such as Spy++, which a member mentioned at Anandtech, and the tool to monitor a specific thread in Visual C++.

Can you give me a quick walkthrough? I just need the order such as "1) select this 2) begin 3) look."

I'm afraid I don't have the time to teach you how to use the VC++ Debugger. Have a read of the Help, that should be enough to get started. There is also a good book by John Robbins called "Debugging Applications" MS Press and no doubt lots of stuff on the Web and in the MSJ Articles. John Robbins writes a regular column in MSJ/MSDN.

You absolutely have to know how to use the VC++ Debugger if you want to do any serious development work, especially if you are multithreading.

Neville Franks, Author of ED for Windows. www.getsoft.com

valikac30-Apr-02 12:35

30-Apr-02 12:35

Okay. Thanks.

Kuphryn

Re: Possible Problem

valikac30-Apr-02 12:59

30-Apr-02 12:59

Hi.

I believe I have figured out the problem. Here is a scenario. Let say you have a program with splitter window. There are two views and both are CEditView. Let say the top view calls a worker thread. While the worker thread is active, you focus the lower view and begin typing. What is the chance that the worker thread will never get deleted?

I just simulated the scenario above using a very simple program with a progress bar. If I focus on another window wile the progress bar is active, the program will not delete the progress bar, period.

I can upload the source code to that simple simulation anyone wants to see it.

Thanks,
Kuphryn

Re: Possible Problem

Neville Franks30-Apr-02 16:04