Interesting Multithreading Problem :: MFC

Hi.

I am stuck in the design process of a small program I am working on. Here is the scenario.

-----
- user select an option in the menu
- main thread creates a dialog box w/ process bar
- dialog box's OnInitDialog() sends a message to main frame
- main frame redirects to view
- view creates a worker thread
- worker thread goes through a for loop // (i = 0, 1 < 10000; ++i);
- worker thread posts a message to main frame on every iteration
- main frame redirects message to view
- view calls a function in dialog box to update process bar
-----

Okay. The design above works fine. Here is one drawback. Even though the worker thread does all the processing (for loop), the main thread is *inaccessible* as it calls the function in the dialog box to update the process bar.

I would like to redesign that part of the program so that even as the worker thread is processing the for loop and as *some thread* updates the process bar, the user can still navigate the program.

Do I need to create a worker thread to update the progress bar? Do I need a UI thread? The reason I kept the dialog box as part of main thread is because according to Prosise, it is best to keep UI related objects in main thread.

Thanks,
Kuphryn

>>> UI related objects in main thread.

Good advice. I always have my UI in my main thread.

As to your problem, not quite sure what you mean. Your worker thread is doing the work, and should be sending your main thread, (UI thread), messages with it's progress that your main thread will read and treat with the same priotrity as any other UI actions.

Okay.

The design works fine.

- worker thread handles data processing
- main thread (view) sends messages to dialog box
- dialog box updates the progress bar

The problem is that I believe the process of updating the progress bar is *considered* as part of the main thread. I think the reason is because the dialog box itself is declared in view (main thread).

need three *independent* processes.

1) data processing
2) dialog box/progress bar updating
3) main thread is idling thus keeps the program from "locking."

Problem: Program seems to "lock" even though the data processing is done in the worker thread.

Question: I believe the reason it seems to "lock" is because as main thread sends message to dialog box to update the progress bar and as the dialog box update the progress bar, the frame considers the entire process (message + updating) as being in the main thread. I need to know a way to make everything separate.

Kuphryn

>>> The design works fine.

If it did, we wouldn't be having this discussion!

>>>
the frame considers the entire process (message + updating) as being in the main thread.
<<<

Well, it is. Your main window proc and your dialog proc are running in the same thread. The worker thread is doing something else. They each have their own message processing loop though, so when a message arrives in onbe or the other loop, it should not lock the other.

I'm afraid I don't know how to help you in detail as you are using MFC.

Okay.

I have consider several different design schemes. One of which is passing a pointer of a dialog box created in view into the worker thread. There, the worker thread can update the dialog box's progress bar. However, I do not think that will solve the problem of "locking." The reason is the dialog box belongs to view, thus it is still apart of view and the main thread. That leaves me with two alternatives opposites of one another.

Alternative #1
- create the dialog box first
- message view after InitDialog()
- view active a function inside of the dialog box
- function instantiate a worker thread that is *part of dialog box*
- worker thread will update the progress bar directly

Alternative #2 (opposite #1)
- create a worker thread
- create a dialog box w/ progress bar *inside of worker thread*
- update the progress bar directly

From the two alternatives, which one do you think is best? I want to make the design as "safe" as possible i.e, non-volatile.

Please mention any ideas you may have.

Thanks,
Kuphryn