<转>windows 下 线各同步方法

This first example illustrates two unsynchronized threads. The main loop, which is the primary thread of a process, prints the contents of a global array of integers. The thread called "Thread" continuously populates the global array of integers.

Note in this sample output, the numbers in red illustrate a state where the primary thread preempted the secondary thread in the middle of populating the values of the array:

81751652 81751652 81751651 81751651 81751651

83348630 83348630 83348630 83348629 83348629

What if your main thread needed all elements of the array to processed prior to reading? One solution is to use a critical section.

Critical section objects provide synchronization similar to that provided by mutex objects, except critical section objects can be used only by the threads of a single process. Event, mutex, and semaphore objects can also be used in a single-process application, but critical section objects provide a slightly faster, more efficient mechanism for mutual-exclusion synchronization. Like a mutex object, a critical section object can be owned by only one thread at a time, which makes it useful for protecting a shared resource from simultaneous access. There is no guarantee about the order in which threads will obtain ownership of the critical section, however, the system will be fair to all threads.

A mutex object is a synchronization object whose state is set to signaled when it is not owned by any thread, and non-signaled when it is owned. Only one thread at a time can own a mutex object, whose name comes from the fact that it is useful in coordinating mutually exclusive access to a shared resource. For example, to prevent two threads from writing to shared memory at the same time, each thread waits for ownership of a mutex object before executing the code that accesses the memory. After writing to the shared memory, the thread releases the mutex object.

Two or more processes can call <code>CreateMutex</code> to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving the user of the responsibility of ensuring that the creating process is started first. When using this technique, you should set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.

Multiple processes can have handles of the same mutex object, enabling use of the object for interprocess synchronization. The following object-sharing mechanisms are available:

A child process created by the <code>CreateProcess</code> function can inherit a handle to a mutex object if thelpMutexAttributes parameter of <code>CreateMutex</code> enabled inheritance.

A process can specify the mutex-object handle in a call to the <code>DuplicateHandle</code> function to create a duplicate handle that can be used by another process.

A process can specify the name of a mutex object in a call to the <code>OpenMutex</code> or <code>CreateMutex</code> function.

Generally speaking, if you are synchronizing threads within the same process, a critical section object is more efficient.

What if we want to force the secondary thread to run each time the primary thread finishes printing the contents of the global array, so that the values in each line of output is only incremented by one?

An event object is a synchronization object whose state can be explicitly set to signaled by use of the <code>SetEvent</code> or<code>PulseEvent</code> function. Following are the two types of event object.

Object

Description

Manual-reset event

An event object whose state remains signaled until it is explicitly reset to non-signaled by the <code>ResetEvent</code>function. While it is signaled, any number of waiting threads, or threads that subsequently specify the same event object in one of the wait functions, can be released.

Auto-reset event

An event object whose state remains signaled until a single waiting thread is released, at which time the system automatically sets the state to non-signaled. If no threads are waiting, the event object's state remains signaled.

The event object is useful in sending a signal to a thread indicating that a particular event has occurred. For example, in overlapped input and output, the system sets a specified event object to the signaled state when the overlapped operation has been completed. A single thread can specify different event objects in several simultaneous overlapped operations, then use one of the multiple-object wait functions to wait for the state of any one of the event objects to be signaled.

A thread uses the <code>CreateEvent</code> function to create an event object. The creating thread specifies the initial state of the object and whether it is a manual-reset or auto-reset event object. The creating thread can also specify a name for the event object. Threads in other processes can open a handle to an existing event object by specifying its name in a call to the <code>OpenEvent</code> function. For additional information about names for mutex, event, semaphore, and timer objects, see Interprocess Synchronization.

A thread can use the <code>PulseEvent</code> function to set the state of an event object to signaled and then reset it to non-signaled after releasing the appropriate number of waiting threads. For a manual-reset event object, all waiting threads are released. For an auto-reset event object, the function releases only a single waiting thread, even if multiple threads are waiting. If no threads are waiting, <code>PulseEvent</code> simply sets the state of the event object to non-signaled and returns.

The MSDN News for July/August 1998 has a front page article on Synchronization Objects. The following table is from that article:

Name

Relative speed

Cross process

Resource counting

Supported platforms

Critical Section

Fast

No

No (exclusive access)

9x/NT/CE

Mutex

Slow

Yes

Semaphore

Automatic

9x/NT

Event

Metered Section