C / C++ / MFC

10-Apr-07 0:56

Hi all,
I am creating a dialog app that has a button. When the button is pressed, in OnButton function of the dialog's cpp it creates a thread (I am using CreateThread())that runs some task. I will have to wait for the task's completion by watching the thread's termination via WaitForSingleObject(hThread, INFINITE) there. Now, the thread 's execution may take seconds so the WaitForSingleObject() would actually block windows messages and the dialog window "freezes" during the time. I'd love to NOT have the dialog frozen but simply have the button disabled during the thread task's execution. As now I have two ways in mind:

1. Use Timer and places the thread creation process in the Timer's function instead. Disabling and re-enabling button can be directly done in the function.
2. Create a main thread that does the thread creation process. The main thread will disable and enable the button via PostMessage().

I am just wondering what an appropriate approach would be to solve this problem?

Thanks in advance,
Best Regards,
Johnny

cp987610-Apr-07 1:25

cp9876

10-Apr-07 1:25

Why not do something simple like:

1. disable button
2. create and start thread
3. when thread completes it posts a message to your dialog where you enable the button

Sort of like your (2), but guarantees the button disabled when thread starts. The dialog can still receive timer messages if you need a watchdog.

Peter

"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."

J.B.10-Apr-07 1:37

10-Apr-07 1:37

Thanks a lot for the reply, Peter,

This would work partially. But I think this is will not solve the frozen dialog window problem I am having, as long as I use WaitForSingleObject() or WaitForMultipleObjects() (multiple tasks executed at once) in my dialog's cpp. I have to wait until all the thread are terminated to calculate the total execution time. That's why I thought about putting WaitForSingleObject() or WaitForMultipleObjects() in another thread or Timer which creates the (threaded) tasks, without blocking dialog's window messages.

I hope it makes sense.

Thanks again,
Best Regards,
Johnny

Roger Stoltz10-Apr-07 1:48

10-Apr-07 1:48

J.B. wrote:
I will have to wait for the task's completion by watching the thread's termination via WaitForSingleObject(hThread, INFINITE) there.

Then there's really no point in having a second thread if you're still doing things in serial. The implementation misses the point of multithreading.

I suggest you spawn the thread as you already do, but continue after the thread is created and don't wait for it.
When the thread has finished its task it should post a message to the main thread/window to inform the main thread that it has finished. In the message handler you can then enable your button again and do whatever you have to do in order to clean up.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

David Crow10-Apr-07 2:10

David Crow

10-Apr-07 2:10

Roger Stoltz wrote:
Then there's really no point in having a second thread if you're still doing things in serial. The implementation misses the point of multithreading.

Agreed. It's amazing how many folks start doing Windows development synchronously.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

Stephen Hewitt10-Apr-07 17:52

Stephen Hewitt

10-Apr-07 17:52

DavidCrow wrote:
Agreed. It's amazing how many folks start doing Windows development synchronously.

I know what you mean, and it is an issue. I don’t find is surprising however; its natural to think sequentially and if you're used to writing console applications even more so.

Steve

cp987610-Apr-07 2:18

cp9876

10-Apr-07 2:18

That's what I was trying to describe - you did a better job!

Peter

"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."

Stephen Hewitt10-Apr-07 17:49

Stephen Hewitt

10-Apr-07 17:49

Roger Stoltz wrote:
Then there's really no point in having a second thread if you're still doing things in serial. The implementation misses the point of multithreading.

While true to a large degree this is not always the case. For example, you may be doing a long task and want to keep the UI responsive or even if the UI is disabled you still want the application to repaint itself while the task is in progress. You could scatter message pumps throughout the long task but this is not always possible and even when it is it may not be practical.

Steve

Roger Stoltz10-Apr-07 21:58

10-Apr-07 21:58

I admit I have used ::MsgWaitForMultipleObjects(...) in the way you're referring to a couple of times. But those cases were very specific.
You can also get in trouble with re-entrancy with Chaos and Mayhem following if you're not careful. There was nothing in J.B.'s post that implied to me that this could be such a rare case, that's why I suggested the most common, straight-forward and less error prone way to do it.

I also think you're missing my point Steve.
I wrote that "the implementation misses the point of multithreading" referring to J.B.'s call to ::WaitForSingleObject(...) blocking the main thread during the wait. In that situation he would actually gain on doing the worker thread task in the main thread.
I intentionally phrased it that way leaving the possibilities open for the rare cases you're thinking about, even though I doubt this would be one of them.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

J.B.10-Apr-07 20:59

10-Apr-07 20:59

Thanks a lot for the suggestion Roger,
I am wondering where I should close the thread's handle (CloseHandle(hThread)) if I do not check for its actual completion. Receiving the message handler's call does not mean the thread's already returned I think? Another problem is that my task may contain multiple thread creations at the same time, the window would need to know when they all terminated too, which then I will get their exit codes for processing(GetExitCodeThread) as well as retrieve a timestamp at the time.

Some sort of "wait-until-all-done" is still needed for my case I think? And obviously that shouldn't be done in the main window. That's why I thought about creating a thread or a timer which creates and does my thread tasks.

Thanks again,
Best Regards,
Johnny

Roger Stoltz10-Apr-07 21:39

10-Apr-07 21:39

In short, here's what you should do when the thread has finished its work:
1. Post a user defined message with ::PostMessage(...) to the main thread to inform it that the worker thread is terminating.
2. In the message handler you wait on the thread handle to know when the thread has terminated.
3. [Optional] Get the exit code of the thread with ::GetExitCodeThread(...).
4. Close the thread handle with ::CloseHandle(...).

Read this[^] excellent article for more info about how to use worker threads.

Regarding your problem with multiple worker threads I suggest that you post the thread ID from the worker threads with the user defined message.
You should have a mapping between thread IDs and their handles. In the message handler you get the thread ID, look up the thread handle in the map and continue from #2 above. Don't forget to remove the thread ID and its handle from the map when you're done with it in the message handler.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

J.B.21-Apr-07 23:58

21-Apr-07 23:58

Thanks again Roger,
for very informative reply and link. They helped greatly.

Best Regards,
Johnny

Roger Stoltz22-Apr-07 9:50

22-Apr-07 9:50

J.B. wrote:
Thanks again Roger,
for very informative reply and link. They helped greatly.

You're most welcome Johnny.
I'm pleased to hear that I was able to help you, so thanks for telling me. Smile | :)

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown