Concurrent operations Windows Vista new synchronization Primitives

This article discusses:

Condition variable

Slim reader lock/writer lock

Initialization at a one-time

Check the lock carefully.

This article uses the following techniques:

Windows Vista, C + +

Directory

Condition variable

Slim reader lock/writer lock

Initialization at a one-time

Conclusion

Windows Vista comes with a series of exciting new technologies for developers, including Windows®presentation Foundation, Windows Communication Foundation, and Windows Workflow Foundation. In fact, Windows Vista™ has introduced too many new. NET-friendly technologies, so it's easy to overlook all the new features and functionality that native C + + developers can use for their applications.

In this article, we'll discuss some of the new Windows Vista features that affect native C + + developers. We will highlight several new thread synchronization features introduced in the new operating system: Condition variables, Slim reader lock/writer locks, and one-time initialization.

Condition variable

The condition variable has been in the other thread library for some time, but unfortunately it was omitted from the Windows SDK. A conditional variable is primarily used to synchronize a set of threads based on the results of some conditional tests. Although this can be done by using an existing synchronization structure combination, the condition variable has the ability to release the acquired lock and enter the hibernation state through an atomic operation. It also provides a clearer and less error-prone method for implementing the desired behavior.

The Windows SDK for Windows Vista (downloadable) exposes the conditional variables of the condition_variable structure. You can create the structure using the Initializeconditionvariable function. There is no function to clean or destroy the condition_variable structure because the underlying implementation does not need it.

By using the function sleepconditionvariablecs (when using a critical section) or SLEEPCONDITIONVARIABLESRW (when using a Slim reader lock/writer lock), you can have the thread wait for the condition variable. When another thread calls Wakeconditionvariable or wakeallconditionvariable, these hibernate threads are freed, depending on whether the calling thread is a thread or all threads that want to release the wait condition variable.

Common producer/consumer issues represent situations in which conditional variables can be used. This is a typical example of a producer generating data and placing it in a buffer, while the consumer crawls the data fragment to be processed from the buffer. This issue identifies a requirement that the producer does not attempt to add data to the filled buffer, and that the consumer does not attempt to crawl the data from the empty buffer. We will analyze this situation to show you how the conditional variable is helping to solve the problem.

For this example, we will create a single producer thread that transmits numeric data to the Shared queue. We then create five consumer threads. Each consumer thread will transfer a project from the queue and process it. When the current data segment is processed, the consumer thread loops and repeats the process indefinitely.

In earlier versions of Windows, Win32 events and key section combinations could be used to address producer/consumer issues. Critical sections protect shared resources, avoid concurrent access, and event signals when resources are available for use by consumers.

When we first tried to solve this problem, we used the Standard Template library (Standard Template Libraries, STL) integer lists as shared resources. Since the list is dynamically expanded, we do not need to use events to signal when the list is not filled, we just need to know when it is not empty so that the user knows that there is content to use. (If you plan to use a fixed-size array to hold a shared queue, you need an event that is not full to ensure that you do not write excessive content to the buffer.) We then declare and initialize the Critical_section object and the automatic reset event that describes when the list is not empty.

The producer thread shown in Figure 1 will first attempt to get the critical section and, if successful, will then insert an integer value at the end of the shared list. The thread then releases the critical section and sets a Non-empty event. Because we are using an automatic reset event, we only release a thread that waits for this event. The consumer thread shown in Figure 1 will see if the queue is empty. If the queue is not empty, the thread will transfer a project and release the key section. If the queue is empty, the consumer thread returns to hibernation and waits for a non-empty event. When the first consumer thread is busy processing items that it transfers from the queue, the producer wakes up another consumer thread to pick up the next job to make sure the queue is moving.