Mutex Wait Is FIFO But Can Be Interrupted

Last reviewed: January 17, 1997
Article ID: Q125657
The information in this article applies to:
  • Microsoft Win32 Application Programming Interface (API) included with:

        - Microsoft Windows NT versions 3.5, 3.51, 4.0
    

SUMMARY

A mutex is a synchronization object that is signaled when it is not owned by any thread. Only one thread at a time can own a mutex. Other threads requesting the mutex will have to wait until the mutex is signaled. This article discusses the order in which threads acquire the mutex.

MORE INFORMATION

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

It is important to remember that Windows NT can interrupt the wait and that this will change the order in which threads are queued. 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. For example, each time you enter the debugger (hit a breakpoint, execute OutputDebugString(), and so on), all application threads are suspended. Suspending a thread causes the thread to run a piece of code in kernel mode. When you continue from the debugger, the threads are resumed, causing them to resume their wait for the mutex, but possibly in a different order than before. In this case, it does not look like the mutex is acquired in FIFO order. Some threads may be unable to acquire the mutex when the application in run under the debugger.

NOTE: This implementation detail is subject to change. Windows 95 and other platforms that support the Win32 API may adopt different strategies.

Most programs do not usually need to make any assumption about this behavior. The only class of applications that should be sensitive to mutex claim and release throughput are real-time-class applications. If throughput is of importance to a program, critical sections should be used wherever possible.


KBCategory: kbprg
KBSubcategory: BseSync
Additional reference words: 3.50 3.51 4.00 windbg ntsd


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: January 17, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.