Rogue Wave banner
Previous fileTop of DocumentContentsIndexNext file

8.3 Synchronization Mechanisms

The purpose of this section is to describe the Win32-specific synchronization mechanisms.

8.3.1 Mutex Acquisition Ordering

In Win32, threads that are blocked on a mutex are handled in a first in, first out (FIFO) order; the first to wait on the mutex will be the first to receive the mutex, regardless of thread priority.

There is an exception to this rule; Windows NT can interrupt a waiting thread, resulting in a change in the wait order. A kernel-mode asynchronous procedure call (APC) can interrupt a user-mode thread's execution at any time. Once the normal execution of the thread resumes, the thread will again wait on the mutex; however, the thread is placed at the end of the wait queue.

An example of this behavior can be found each time you encounter a debug breakpoint. The breakpoint forces entry into the debugger, which immediately suspends all threads, forcing them to exit any mutex waits so they can run a piece of kernel-mode code. When you continue from the debugger, the suspended threads are resumed, causing them to reenter their wait for the mutex, but possibly in a different order than before. Therefore, when the synchronization process is viewed from the debugger, it may not appear as though the mutex is acquired in FIFO order. This behavior may cause synchronization problems, such as priority inversion, to appear when running under the debugger, but not in normal execution.

This implementation detail applies only to Windows NT. Windows 95 and other platforms that support the Win32 API may use different strategies.

Most programs will not need to worry about this behavior. Only those applications that might experience priority inversion need consider this behavior.

8.3.2 Handling Unreleased Locks

When the Win32 call WaitForSingleObject attempts to acquire a lock that was held, but never released, by a thread which has since terminated, an error code is returned. RWMutexLock correctly processes this as an error. However, WaitForSingleLock acquires the lock, even though it returns an error code. You can avoid this confusing situation by making sure that threads always release all locks before terminating.


Previous fileTop of DocumentContentsIndexNext file

©Copyright 2000, Rogue Wave Software, Inc.
Contact Rogue Wave about documentation or support issues.