Multithreading :: MFC

[kuphryn]

Hi.

I am working on my first "real" Windows program. I am at a point in the implementing process where I see a need to multithread one specific job. I will give a good example of something that is very similar to what I am to implement. I will then give my thoughts on a possible solution. I have no prior experience with multithreading, but Jeff Prosise's book does wonders.

I am design a dialog box with a progress bar *very similar* to
the one you see when you download a file using IE. When you download a large file (your download bandwidth is slow), you can see the progress of the download process. The process bar is easy to implement. The part that makes IE progress bar special is you can *still use* IE during the download process. The key is multithread.

Here is my design.

-----
-User activate a feature (via menu)
-View creates a dialogbox w/ progressbar (position 0)
-Dialogbox sends a message to MainFrm.
-MainFrm redirect message to View
-View calls function in Document to begin data processing
-View also passes the function a pointer to dialogbox
-Document starts a new thread (worker thread)
-Thread begin processing data
-Thread sends message back to Document when applicable
-Document calls updated progressbar via pointer to dialog
-----

Again, this is my first experiment with multithread. Is there anything wrong with the design above? I left some small features out. I will include it soon.

Thanks,
Kuphryn

 

[bsobel]

> The part that makes IE progress bar special is you can *still use* IE during the download process. The key is multithread.

First, what your planning should be fine. But MFC and mult-threaded apps can be a bear sometimes. Not saying don't do it, just don't get too frustrated if you run into some problems that take a bit longer than you'd like to debug/fix.

Second, I wanted to clarify your above statement. Multithreading is ONE technique that IE may be using to handle the background download. It is not the only one (e.g. IO completion ports would be another reasonable way to implement this).

Bill

 

[kuphryn]

Thanks.

Yeah, I am sure Microsoft implemented interesting designs in IE as with most other applications.

Kuphryn

 

[RSMemphis]

This is actually rather easy to do with AfxBeginThread(void *function, void *environment);

the second parameter allows you to pass any pointer you wish, and you can therefore access datastructures in the calling thread.
The working thread can even end itself.

So, your main app has a variable called "progress" or whatever.
You pass "this" as the second parameter, which gives your worker thread access to some data variables in the main thread (or functions) if they are not private or protected.

Update this variable as you like, and your main app can run the status bar.

It's actually quite easy, I communicate with pointers like this all the time - Messages are ok, too, but less convenient.

 

[kuphryn]

Thanks.

One reason I wanted to message main and redirect the message to view is to keep the worker thread specific. It is certainly possible to pass the worker thread a reference to a data structure with a pointer to the dialog box, but passing some MFC core functions and objects into a worker thread can cause major problems. According to Jeff Prosise, MFC core functions react differently to worker thread. For example, Prosise gave a working example on passing CWnd * as a data structure into a worker thread. However, a problem can occur if you pass in a CDocument.

In general, I prefer pass the worker thread core C++ objects (bool, int, char, string, STL) and my own functions.

I have considered using a UI thread. However, according to Prosise, he advices to keep UI related features in the main thread instead of a worker thread or UI thread. One reason is you cannot *pass handle and/or pointer* of many MFC core functions into a worker thread via a reference to a struct. The bottomline is that he advices to keep all UI related features in the main thread. I think it is there for a reason. There is definitely a use for it and situations to would call for UI thread. In most cases when you are manipulating data or calculating something, I believe worker threads are more suited

Kuphryn

 

[RSMemphis]

You are right.
What I do is the following:

In the main thread I have a function that gets a message every second (very easy to do in MFC). It reads the variable that the worker thread has a pointer to, and displays the value of the variable.

It may look a little dirty, but it's really not.