There are two types of threads in MFC. Worker and User Interface. Here, I will discuss how to use a worker thread.First, let’s discuss some multi-threading basics. Each application has what we call a process. Usually, an application has only one process. This process defines all the code and memory space for the application. You can use the Window Task Mananger to view running processes.
You could possibly view a thread as a process within a process. It is an independently (mostly) running sub-process, that the CPU can task and switch to like any other process on the machine.
Under 16-bit Windows, you could have mulitple processes (i.e., many programs running: multi-tasking). However, each application was limited to its one main process. It was multi-tasked, not multi-threaded. With 32-bit Windows, applications could spawn their own threads or sub-processes.
Â
Threads have priority levels. The explanation of exactly how Windows manages these in determining how much processor time each receives is a topic you can find in the MSDN literature. Basically, higher priorities receive more time.
When your Win32 program creates a thread, you specify its priority level. By default, it has the same priority as the calling thread.
There are two main issues you must deal with when using threads: 1) Inter-thread communication, and 2) inter-thread object access.
I’ll leave object access for part II of this tutorial.
Communication
The easiest way to communicate among threads in your application is with messages. Since this tutorial deals with worker threads, we’ll restrict this to having the worker thread post messages to the main application thread.
ThreadFunc()
So, now let’s walk through creating a simple worker thread that does nothing but update the progress control in a dialog box.
I’m going to assume you know how to create a dialog box, with a progress control, bound to a member variable in the dialog class. Do that now. You could also create a button that starts the thread.
OK, the first thing you need to do is create the thread’s controlling function. This can either be global or a class member, but I prefer to make it global because this separates the thread from the main process in my mind.
[code lang=”cpp”]UINT MyThreadFunc(LPVOID lParam); [/code]
All MFC thread “controllers” must be declared like that.
To call this function in a thread, we use the following code:
[code lang=”cpp”]
CWinThread *pThread = AfxBeginThread(MyThreadFunc, NULL, THREAD_PRIORITY_NORMAL, 0, 0); [/code]
This creates a separate thread using the MyThreadFunc function, passes a NULL for its one parameter, sets the priority to normal, gives it the same stack size as the calling thread, and starts the thread immediately. If the last parameter here is CREATE_SUSPENDED instead of 0, then the thread is created, but it does not start running until you explicitly tell it to.
This will successfully create a thread, which will run until MyThreadFunc returns. However, the calling thread will not know when that thread is done. Somehow, we have to pass the thread some information about the calling program.
Passing Information To a Thread
A thread controller can only have one parameter–the LPVOID argument. Therefore, it is often convenient to wrap up all the information we want to send the thread into a single struct:
[code lang=”cpp”]
typedef struct THREADINFOSTRUCT {
HWND hWnd;
CString someData;
} THREADINFOSTRUCT; [/code]We can put any data we want in that structure, but one that should always be in there is a handle to the thread’s parent window. This will allow us to communicate with it.
Now, before we start the thread, let’s allocate some space for this structure. If we merely declare it on the stack with
[code lang=”cpp”]THREADINFOSTRUCT tis; [/code]
then as soon as this data goes out of scope, it will be destroyed. So let’s put it on the heap:
[code lang=”cpp”]THREADINFOSTRUCT *tis=new THREADINFOSTRUCT;
tis->hWnd=m_hWnd;
tis->someData=”This is in a thread.”; [/code]
And now we call the same function as before, passing tis:
[code lang=”cpp”]CWinThread *pThread = AfxBeginThread(MyThreadFunc,tis,
THREAD_PRIORITY_NORMAL,0,0); [/code]
OK, now we can pass some information to the thread. How do we let the thread tell the main process what’s going on?
Communicating with Threads
We can communicate to the calling window via a windows messages. First we have to define our own custom messages in our dialog class’s header file:
[code lang=”cpp”]#define WM_USER_THREAD_FINISHED (WM_USER+0x101)
#define WM_USER_THREAD_UPDATE_PROGRESS (WM_USER+0x102) [/code]
We also have to provide handlers for these messages in our dialog class:
[code lang=”cpp”]
afx_msg LRESULT OnThreadFinished(WPARAM wParam, LPARAM lParam);
afx_msg LRESULT OnThreadUpdateProgress(WPARAM wParam, LPARAM lParam); [/code]
All custom message handlers must follow that generic template. But we can interpret the parameters any way we want.
We must also manually update the message map with these two lines:
[code lang=”cpp”]
ON_MESSAGE(WM_USER_THREAD_FINISHED, OnThreadFinished)
ON_MESSAGE(WM_USER_THREAD_UPDATE_PROGRESS, OnThreadUpdateProgress) [/code]
And now we add the function definitions somewhere in our source file:
[code lang=”cpp”]
LRESULT CMyDialog::OnThreadFinished(WPARAM wParam, LPARAM lParam)
{
AfxMessageBox(“Thread has exited”);
return 0;
}LRESULT CMyDialog::OnThreadUpdateProgress(WPARAM wParam, LPARAM lParam)
{
m_progress.SetPos(100*(int)wParam/(int)lParam);
return 0;
}
[/code]
So what should our thread do? In this example, not much:
[code lang=”cpp”]
UINT MyThreadFunc(LPVOID lParam)
{
THREADINFOSTRUCT* tis=(THREADINFOSTRUCT*)lParam;
for (int i=0;i<100;i++) {
PostMessage(tis->hWnd,WM_USER_THREAD_UPDATE_PROGRESS,i,100);
Sleep(100);
}
PostMessage(tis->hWnd,WM_USER_THREAD_FINISHED,0,0);
delete tis;
return 0;
} [/code]
Let’s analyze this. First we typecast the function’s argument into the structure type we passed. Then we just run through a simple loop that sends a message to the main thread to update the progress bar. We sleep for 100 ms just so it doesn’t go too fast that we don’t see it.
Next we send a message saying that our thread is finished.
Finally we delete the pointer to tis; Wait a second! Didn’t we define that in the main thread??? Yes, and it’s perfectly fine to allocate memory in one thread and free it in another. As long as we the programmer keep track of where things are happening. Alternatively, we could have set a class variable to hold that structure, and delete it in the [code lang=”cpp”]OnThreadFinished[/code] functioned. Either way is acceptable.
The function then returns, and the thread ends.
That’s all! It’s so easy! To see a working example project, look in the code tools section.
Of course, we can easily make it more complicated. Part II will talk about some synchronization methods used to control simultaneous access to objects from multiple threads. Now things can start becoming fun…
©2004 Ben Watson