While there have been several resources written to cover creating threads using Microsoft Win32 C functions, there is a shortage of information on how to handle threads in C++. Since C++ programmers can use C functions in their programs, threading is typically done in C, at the cost of some functionality and the object modeling available to applications written in C++. By threading with the methods described in this article, you can invoke any member function of a C++ class in a separate thread.
Applies to:
Microsoft Windows Powered Pocket PC 2000
Microsoft eMbedded Visual C++ version 3.0
Gotchas
None
Languages Supported
English
Planning Your Application
Application design is an article (or a book) in itself, but suffice it to say that your application development will go much more smoothly if you have a plan to follow. Most likely, the best way to plan the threads in your application is either on paper or on a whiteboard.
For each task that will take longer than a fraction of a second, consider making it a thread, since performing any task in the same thread as the user interface will cause the user interface to "freeze" while that task is performed. There are plenty of applications out there that do everything in the same thread as the user interface, but in general the development community should move away from this type of programming, since it tends to make applications feel sluggish and unresponsive.
Creating Classes with Thread Methods
Starting a thread is only a little more complex than calling a function. By calling the CreateThread() or AfxBeginThread() functions, and passing the address of your own function, Microsoft Windows will call your function in a separate thread. AfxBeginThread is used for MFC (Microsoft Foundation Classes) applications, and it calls the CreateThread function,
Typically, a C++ programmer who is familiar with multithreading in C will try to pass a member function of their class to the CreateThread() or AfxBeginThread() functions. Unfortunately, C++ member functions don't have a specific memory address.
Ah, you might be thinking, but what about static methods? Yes, static methods do have a fixed address, and can in fact be passed to CreateThread() or AfxBeginThread() successfully. Unfortunately, static methods do not relate to any specific instance of a class, so they can't access any data members of the class that aren't also static (making them pretty useless as a thread function).
Fortunately, there's a very good solution to the problem:
- Create a nonstatic public method for the thread in your class. This method will take no parameters, and will return a DWORD.
- Create a static protected method for the thread with a similar name. I suggest adding the suffix "_thread" so that if your nonstatic method was called PerformSearch," the corresponding static method would be called PerformSearch_thread. This method will take one parameter, a pointer to its own object class, and will return a DWORD.
- In the static method, call the nonstatic method of the object pointer passed in as a parameter. For example, if the parameter is called pThis, call pThis->PerformSearch(). This step is very important, because by calling back into a nonstatic method, the thread is then granted access to the private and protected data members of the class.
- Define a static, manual reset event handle called m_hEventTerminate. This handle will be used to signal the threads that they should terminate.
- Define an array of thread handles for each thread the application will be starting. Using an array now will make it easier to handle application termination later.
- Spawn the thread from inside the class. Do this by calling CreateThread() or AfxBeginThread() and pass the static method, and the object's this pointer as the parameter. Typically, spawn the threads either in an initialization method, often called from the class constructor.
Figure 1: The majority of your class methods can execute in one thread, and specific methods can be run in another thread.
A simple example of the process is available for download at the Virtual Office Systems Web site.
Conclusion
There is certainly more to good threading techniques than can be covered in a brief article like this one. As a developer, you should strive to use the tools at your disposal, and "C style" multithreading can now be left in C, where it belongs.