From: Drew on
I'm trying to get some more experience using multithreading. My idea is to
have a dialog based app that has a button to create a new UI Thread each
time it is pushed. The thread ID will show up in a list box on the dialog.
The UI thread will launch a dialog that starts a worker thread to increment
an integer in an endless (or not) while loop and display a listbox that
shows the current value. If the UI thread dialog is closed or cancelled it
will stop the worker thread and signal the main dialog to remove the thread
ID from the list. If the user selects a thread ID in the main dialog and
presses a button it will signal the UI thread to terminate, closing it's
dialog and ending the dialog's worker thread. If the user closes the main
dialog it will signal all UI threads and their respective dialogs (and their
worker threads) to terminate. I was thinking of using a std::map<DWORD,
CWinThread*> to hold the thread IDs and the threads created in the main
dialog. Can someone point me to one or more resources that can help me to
achieve my goals?

Thanks,
Drew


From: Joseph M. Newcomer on
This is a Really Bad Idea.

First, never, ever create user-visible objects in a UI thread. The name is confusing and
misleading. It really means "a thread with a message pump" and creating a dialog in it
causes all kinds of problems because the messages sent from the dialog to its parent
(general window messages whch are always generated) must be handled via cross-thread
SendMessage which is the core of the Really Bad Idea.

The most effective design rule is the one I just gave: "Never create a user-visible window
in a secondary thread". As an indicator, beginners like yourself, who have not done
threading almost always try to do this, and the highly-experienced programmers such as
most of the MVPs will avoid ever doing this, and we know all the obscure rules that you
have to worry about.

You have not indicate how a thread would be terminated, but you must NOT use
TerminateThread to do this; you must *ASK* the thread to terminate itself. NEVER call
::ExitThread or any method that calls it, such as AfxEndThread. To terminate a UI thread,
call ::PostQuitMessage from inside it, or PostThreadMessage(WM_QUIT) from outside it

Generally, there isn't much you can do with thread IDs, and you have no reason to ever
store them. If the main thread needs to know about the secondary threads (which is rare,
but not unheard of), keep the CWinThread* pointers or the pointers to the derived class
returned by AfxBeginThread. Note that you must NEVER use ::CreateThread to create a
thread; for pure C you must use _beginthread or better still _beginthreadex (note the
documention on these sucks, having been written by amateur writers and will almost
certainly get you into trouble unless you read the Remarks VERY carefully). If you are
writing MFC code, the ONLY way you can create threads is by AfxBeginThread or
CWinThread::CreateThread.

UI threads are not as useful as you think, but the are very good if you have a
low-bandwidth requirement for interthread messaging.
joe

On Fri, 7 May 2010 16:03:30 -0500, "Drew" <dam(a)dam.com> wrote:

>
>I'm trying to get some more experience using multithreading. My idea is to
>have a dialog based app that has a button to create a new UI Thread each
>time it is pushed. The thread ID will show up in a list box on the dialog.
>The UI thread will launch a dialog that starts a worker thread to increment
>an integer in an endless (or not) while loop and display a listbox that
>shows the current value. If the UI thread dialog is closed or cancelled it
>will stop the worker thread and signal the main dialog to remove the thread
>ID from the list. If the user selects a thread ID in the main dialog and
>presses a button it will signal the UI thread to terminate, closing it's
>dialog and ending the dialog's worker thread. If the user closes the main
>dialog it will signal all UI threads and their respective dialogs (and their
>worker threads) to terminate. I was thinking of using a std::map<DWORD,
>CWinThread*> to hold the thread IDs and the threads created in the main
>dialog. Can someone point me to one or more resources that can help me to
>achieve my goals?
>
>Thanks,
>Drew
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Jim Beveridge on
Drew,

You might consider a book to help you through the basics. There's a lot to
learn to get started with multithreading. I'm the author of Multithreading
Applications in Win32 and I addressed all of your questions in that book.

Joe Newcomer, the other person who replied, is also a popular author. His
answers are spot-on.

You can get yourself a used copy of the book from Amazon for just over $5.
(I don't make money from these used copies.)

http://www.amazon.com/Multithreading-Applications-Win32-Complete-Threads/dp/0201442345/ref=sr_1_1

Regards,
Jim Beveridge


"Drew" <dam(a)dam.com> wrote in message
news:%23tl0$ii7KHA.1888(a)TK2MSFTNGP05.phx.gbl...
> I'm trying to get some more experience using multithreading. My idea is to
> have a dialog based app that has a button to create a new UI Thread each
> time it is pushed. The thread ID will show up in a list box on the dialog.
> The UI thread will launch a dialog that starts a worker thread to
> increment an integer in an endless (or not) while loop and display a
> listbox that shows the current value. If the UI thread dialog is closed or
> cancelled it will stop the worker thread and signal the main dialog to
> remove the thread ID from the list. If the user selects a thread ID in the
> main dialog and presses a button it will signal the UI thread to
> terminate, closing it's dialog and ending the dialog's worker thread. If
> the user closes the main dialog it will signal all UI threads and their
> respective dialogs (and their worker threads) to terminate. I was thinking
> of using a std::map<DWORD, CWinThread*> to hold the thread IDs and the
> threads created in the main dialog. Can someone point me to one or more
> resources that can help me to achieve my goals?
>
> Thanks,
> Drew
>