InformIT: Visual C++ 6 Unleashed > Win32 Processes, Threads, and Synchronization

Table of Contents

Win32 Processes, Threads, and Synchronization

A process is started by the operating system when an application is launched. The process owns the memory, resources, and threads of execution that are associated with a running instance of an executable program. When the process is started, one thread is initially associated with that process. As long as one thread continues to be associated with the process, the process continues to run.

Understanding Threads

A thread is the smallest schedulable unit of execution in a Windows application. A thread always is associated with a particular process—after the thread is started, it never runs in the context of another process. Although many simple applications use only a single thread, it's not uncommon for more complex applications to use multiple threads over the lifetime of the process.

Threads are scheduled according to their priority. Within a particular priority level, threads are scheduled in a circular (or round-robin) fashion. For example, if three threads are running at priority level 7, and these threads never yield, they will each get the same amount of execution time from the operating system.

The thread with the highest priority level is always running, assuming that it is not waiting for a resource to become available or for an event to occur. A maximum of one thread per system processor is allowed to be in the running state—all other threads are either waiting or are marked as ready. The ready state indicates that the thread is capable of running but is waiting to be scheduled to run.

After a thread begins to run, it continues to run until one of the following actions occur:

The thread exceeds its maximum execution time, known as a quantum. If a thread exceeds its quantum, the thread is placed in the waiting state, and the operating system schedules a new thread to run.
A higher-priority thread becomes runnable. If a low-priority thread is running, and a thread with higher priority becomes runnable (for example, because a resource becomes available), the lower-priority thread immediately is interrupted, and the higher-priority thread begins executing.
The running thread yields by waiting for an event or object.

When a thread is prevented from running because its priority is lower than other threads in the system, it is said to be starved. Threads that run at lower priorities occasionally are given a "boost" in their priority in order to prevent deadlock.

The Need for Synchronization

After you introduce multiple threads into an application, you must plan for problems that simply don't exist in single-threaded programming. For example, the simple act of reading and writing to a global variable must be synchronized properly. Consider this innocent-looking code fragment:

int g_nQueuedRequests = 0;
void QueueRequest(void)
{
    ++g_nQueuedRequests;
    DoSomethingToQueueRequest();
}
void SatisfyRequest(void)
{
    —g_nQueuedRequests;
    DoSomethingToHandleRequestFromQueue()
}

This fragment contains two functions that write to the same variable. In a multithreaded application, it would be very easy to have two threads attempt to modify the variable simultaneously, which would cause the value for the variable to be corrupted. Two basic scenarios exist:

On multiprocessor machines, it's possible for two or more processors to attempt to access the variable at exactly the same time. If your code does not use synchronization primitives from the operating system, a fault definitely will occur.
On uniprocessor machines, multiple threads don't actually execute at the same time—they only appear to do so. It is possible for a thread to be interrupted at any time. Because several machine instructions are required to update the value of a variable, it is possible for a thread to be interrupted in the middle of modifying the value of a variable, allowing another thread to corrupt it.

As illustrated by the preceding code fragment, synchronization is required for all types of data in your application. If it's possible for multiple threads to update a variable, you must provide some sort of synchronization for access.

The simplest types of synchronization primitives are used to manipulate or test the values of 32-bit scalar variables. The following Win32 functions are guaranteed to be atomic and thread safe, even when used with multiple processors:

InterlockedIncrement increments a 32-bit variable and returns the new value.
InterlockedDecrement decrements a 32-bit variable and returns its value.
InterlockedExchange changes the value of a 32-bit variable to a new value and returns the previous value.
InterlockedExchangeAdd increments the value of a 32-bit variable by a specified amount and returns the previous value.
InterlockedExchangePointer changes the value of a 32-bit variable to a new value and returns the previous value. In 64-bit versions of Windows 2000, the parameters to this function are 64-bit values.
InterlockedCompareExchange conditionally sets the value of a 32-bit variable to a new value and returns the previous value.
InterlockedCompareExchangePointer conditionally sets the value of a 32-bit variable to a new value and returns the previous value. In 64-bit versions of Windows 2000, the parameters to this function are 64-bit values.

Variables passed to these functions must be aligned on 32-bit boundaries (64-bit parameters must be aligned on a 64-bit boundary).

Using Multiple Threads in Your Application | Next Section

Previous Section