Summary of Windows
Synchronization Primitives
June 20, 2005
Abstract
This paper summarizes the synchronization primitives available to kernel-mode
drivers for the Microsoft® Windows® family of operating systems.
This information applies for the following operating systems:
Microsoft Windows Vista™
Microsoft Windows Server™ 2003
Microsoft Windows XP
Microsoft Windows 2000
Microsoft Windows NT®
The current version of this paper is maintained on the Web at:
http://www.microsoft.com/whdc/driver/tips/default.mspx
References and resources discussed here are listed at the end of this paper.
Summary of Windows Synchronization Primitives - 2
Disclaimer
The information contained in this document represents the current view of Microsoft Corporation on the
issues discussed as of the date of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot
guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights
under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval
system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, email address, logo, person, place or event is
intended or should be inferred.
© 2005 Microsoft Corporation. All rights reserved.
Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
June 20, 2005 - © 2005 Microsoft Corporation. All rights reserved.
Summary of Windows Synchronization Primitives - 3
Summary of Windows Synchronization Primitives
Microsoft® Windows® supports numerous synchronization primitives, each of which
has unique characteristics. In any situation, the best primitive to use depends on the
operations that require synchronization. The table in this document lists the
synchronization primitives that are available to kernel-mode drivers along with the
characteristics of each primitive. It includes the following information:
Primitive—Lists the name of the primitive, the name of the data types used to
represent it (if any), and the DDIs that acquire and release it.
Usage—Describes the type of synchronization the primitive provides and the
situations in which to use it.
IRQL—Lists the IRQL at which a caller can invoke the primitive and the IRQL at
which code that is protected by the primitive runs.
Effect on APCs—Indicates whether user, normal kernel, and special kernel
asynchronous procedure calls (APCs) can be delivered to the thread while the
primitive is in use. Windows supports three types of APCs:

User APCs run in user mode and are delivered during the unwind from kernel
mode to user mode. This type of APC is used for thread termination and usermode signaling operations.

Normal kernel APCs are used for thread suspension and hard error pop-ups
unless delivery has been disabled using KeEnterCriticalRegion. They run in
kernel mode at PASSIVE_LEVEL

Special kernel APCs run in kernel mode at APC_LEVEL and are used in IRP
completion.
Recursive acquisition—Indicates whether the primitive can be acquired
recursively, and thus whether it can be used safely in reentrant code.
Operating system support—Lists the operating system releases that support this
primitive.
June 20, 2005 - © 2005 Microsoft Corporation. All rights reserved.
Windows Kernel-Mode Synchronization Primitives
Primitive
Usage
IRQL
Effect on APCs
Mutex (KMUTEX)
Provides exclusive access to a
resource. Use in passive-level
code that might be reentered
while holding the lock.
To acquire:
PASSIVE_LEVEL
While waiting to acquire
a mutex: Delivery of
APCs depends on the
values of the WaitMode
and Alertable
parameters to the
KeWaitXxx routine.1
Acquire: KeWaitXxx
During use: No
change
Recursive
acquisition?
Operating
system
support
Yes, by the
same thread
Windows NT
4.0, Windows
2000 and later
All disabled
No
Windows NT
4.0, Windows
2000 and later
Not disabled
No
Windows NT
4.0, Windows
2000 and later
While holding a mutex:
User APCs: Disabled
Normal kernel APCs:
Disabled
Special kernel APCs:
Delivered and executed
Fast mutex (FAST_MUTEX)
Acquire: ExAcquireFastMutex or
ExTryToAcquireFastMutex
Release: ExReleaseFastMutex
Unsafe fast mutex (FAST_MUTEX)
Acquire: ExAcquireFastMutexUnsafe
Release: ExReleaseFastMutexUnsafe
Provides exclusive access to a
resource. Use in passive-level
or APC-level code that cannot
be reentered while holding the
lock.
Provides exclusive access to a
resource. Use in passive-level
or APC-level code that cannot
be reentered while holding the
lock.
The driver is responsible for
ensuring that APCs are not
delivered while it holds the
unsafe fast mutex.
To acquire:
PASSIVE_LEVEL
or APC_LEVEL
During use:
APC_LEVEL
To acquire:
PASSIVE_LEVEL
or APC_LEVEL
During use: No
change
Summary of Windows Synchronization Primitives - 5
Operating
system
support
Primitive
Usage
IRQL
Effect on APCs
Recursive
acquisition?
Guarded mutex (KGUARDED_MUTEX)
To acquire:
PASSIVE_LEVEL
or APC_LEVEL
All disabled
No
Acquire: KeAcquireGuardedMutex or
KeTryToAcquireGuardedMutex
Release: KeReleaseGuardedMutex
Provides exclusive access to a
resource. Use in passive-level
or APC-level code that cannot
be reentered while holding the
lock.
Windows
Server 2003
and later
Critical region
Disables all APCs but does not
raise IRQL to APC_LEVEL.
Does not require
reprogramming the CPU Task
Priority Register (TPR), which
is used for routing interrupts in
the I/O APIC on a
multiprocessor system,
thereby improving
performance over fast
mutexes.
Prevents thread suspension.
User APCs: Disabled
Recursive up
to 2^31 times
Windows NT
4.0, Windows
2000 and later
All disabled
Recursive up
to 2^31 times
Windows
Server 2003
and later
Not disabled
Yes, by the
same thread
Windows NT
4.0, Windows
2000 and later
Enter: KeEnterCriticalRegion
Leave: KeLeaveCriticalRegion
Guarded region
Enter: KeEnterGuardedRegion
Leave: KeLeaveGuardedRegion
Executive resource (ERESOURCE)
Acquire: ExAcquireResourceSharedLite,
ExAcquireSharedStarveExclusive, or
ExTryToAcquireResourceExclusiveLite
Release: ExReleaseResourceForThread
Use in file systems and file
system filters to prevent thread
suspension while holding a
kernel dispatcher object lock
such as an event, semaphore,
or mutex.
Disables all APCs but does not
raise IRQL to APC_LEVEL.
Re-enables APCs after the
thread exits the outermost
guarded region.
Use instead of raising IRQL to
APC_LEVEL.
Provides a read/write lock. Use
in passive-level or APC-level
code that usually requires
shared access, but
occasionally requires exclusive
access.
June 20, 2005 - © 2005 Microsoft Corporation. All rights reserved.
During use: No
change
To acquire:
PASSIVE_LEVEL
or APC_LEVEL
During use: No
change
To acquire:
PASSIVE_LEVEL
or APC_LEVEL
Normal kernel APCs:
Disabled
Special kernel APCs:
Delivered and executed
During use: No
change
To acquire:
PASSIVE_LEVEL
or APC_LEVEL
During use: No
change
Summary of Windows Synchronization Primitives - 6
Recursive
acquisition?
Operating
system
support
Primitive
Usage
IRQL
Effect on APCs
Event (KEVENT)
Blocks execution of the current
thread until some other thread
signals that an event has
occurred.
To acquire:
PASSIVE_LEVEL
or APC_LEVEL
Not disabled. Delivery
of APCs depends on
the values of the
WaitMode and Alertable
parameters to the
KeWaitXxx routine.1
Not disabled; delivery of
APCs depends on the
values of the WaitMode
and Alertable
parameters to the
KeWaitXxx routine.1
All disabled
No thread
ownership
Windows NT
4.0, Windows
2000 and later
No thread
ownership
Windows NT
4.0, Windows
2000 and later
No
Windows NT
4.0, Windows
2000 and later
All disabled
No
Windows XP
and later
All disabled
No
Windows XP
and later
Acquire: KeWaitXxx
Semaphore (KSEMAPHORE)
Acquire: KeWaitXxx
Executive spin lock (KSPIN_LOCK)
Acquire: KeAcquireSpinLock,
KeAcquireSpinLockAtDpcLevel, or
KeTryToAcquireSpinLockAtDpcLevel
Release: KeReleaseSpinLock or
KeReleaseSpinLockFromDpcLevel
Queued spin lock (KSPIN_LOCK,
KLOCK_QUEUE_HANDLE)
Provides shared access to a
resource. Use in passive-level
or APC-level code.
During use: No
change
To acquire:
PASSIVE_LEVEL
or APC_LEVEL
Provides exclusive access to a
resource at
DISPATCH_LEVEL.
During use: No
change
To acquire:
DISPATCH_LEVEL
or lower
During use:
DISPATCH_LEVEL
Provides exclusive access to a
resource at
DISPATCH_LEVEL.
Acquire:
KeAcquireInStackQueuedSpinLock, or
KeAcquireInStackQueuedSpinLockAtDp
cLevel
Release:
KeReleaseInStackQueuedSpinLock, or
KeReleaseInStackQueuedSpinLockFrom
DpcLevel
Interrupt spin lock (KINTERRUPT)
Acquire: KeAcquireInterruptSpinLock
Release: KeReleaseInterruptSpinLock
To acquire:
DISPATCH_LEVEL
or lower
During use:
DISPATCH_LEVEL
Provides exclusive access to a
resource at IRQL greater than
DISPATCH_LEVEL.
On Windows NT 4.0 and
Windows 2000, use
KeSynchronizeExecution
with a SynchCritSection
routine to raise IRQL to DIRQL
for the device.
June 20, 2005 - © 2005 Microsoft Corporation. All rights reserved.
To acquire: DIRQL
or lower
During use: DIRQL
Summary of Windows Synchronization Primitives - 7
Primitive
Usage
IRQL
Effect on APCs
Recursive
acquisition?
Timer object (KTIMER)
Delays execution of current
thread for specified period of
time or performs a one-time or
periodic operation in a DPC
associated with the timer.
To acquire:
DISPATCH_LEVEL
or lower
Not applicable
Not applicable
Acquire: KeWaitXxx
1
During use:
Associated DPC is
called at
DISPATCH_LEVEL
For details, see “Do Waiting Threads Receive Alerts and APCs?” in the Windows DDK.
June 20, 2005 - © 2005 Microsoft Corporation. All rights reserved.
Operating
system
support
Windows NT
4.0, Windows
2000 and later
Summary of Windows Synchronization Primitives - 8
For more information
Locks, Deadlocks, and Synchronization
Windows DDK:
General Driver Information
Kernel-Mode Driver Architecture
Design Guide
Synchronization Techniques
June 20, 2005