At the system level, a thread is an object created by the Object Manager. Like all system objects, a thread contains attributes (or data) and methods (or functions). Figure 14.1 represents a thread object schematically, listing its attributes and methods.
Figure 14.1: A thread object contains attributes and methods
Most of the thread methods have corresponding Win32 functions. When you call SuspendThread, for example, the Win32 subsystem responds by calling the thread’s Suspend method. In other words, the Win32 API exposes the Suspend method to Win32 applications.
NOTE
The Win32 API is a library (or libraries) of methods that are called directly or indirectly by applications to request services performed by the operating system. For a simple example, asking for a list of files or directories is accomplished though an API call. Under DOS, a similar task would be accomplished by calling a DOS interrupt function. Under Windows, the principal remains the same; an API call invokes a system-supplied function to perform a task.
The thread context attribute is the data structure for saving the machine state whenever the thread stops executing. You’ll learn about other thread attributes later in the chapter.
Windows has always protected some internal structures, such as windows and brushes, from direct manipulation; programs that run at the system’s user level (as opposed to the more privileged kernel level) may not directly examine or modify the inside of a system object. Only by calling Win32 API routines can you do anything at all with an object. Windows gives you a handle to identify the object, and you pass the handle to functions that need it. Threads, too, have handles, as do processes, semaphores, files, and many other objects. Only the Object Manager touches the inside of an object.
The function that creates a thread returns a handle to the new object. With the handle, you can do the following:
Under 16-bit Windows, an object has only one handle. The handle may be copied into several variables, but it is still one handle. And when the object is destroyed, all the copies of the handle become invalid. Starting with Windows 95, however, some new objects in Win32 began to work differently. Several threads or processes may have different handles to the same object. Brushes, windows, and device contexts still support only one handle; but a single thread, process, or mutex may have many different handles. As each finishes with the object, it calls CloseHandle. When the last handle closes, the system destroys the object.
NOTE
Although the total number of handles in the system is limited only by available memory, no single process may possess more than 65,536 open handles.