相对ERESOURCE来说，FastMutex的使用比较方便，不用考虑禁APC问题，也不用考虑FastMutex结构体的释放，用完即可以三不管。对于竞争不激烈且读写不明显的情况下，用FastMutex还是不错的。

不过使用过程中要注意其隐藏的陷阱：

1，ExAcquireFastMutex 会提升IRQL至APC_LEVEL，且保存原来的IRQL用以在ExReleaseFastMutex时恢复。所以在嵌套获取FastMutex时要特别注意放锁一定要依加锁顺序反向操作，不然会导致IRQL紊乱。为此系统特别提供了Unsafe操作函数(ExAcquireFastMutexUnsafe及ExReleaseFastMutexUnsafe)，这两个函数不会操作IRQL，但使用上却有前提条件。

2，FastMutex的实现是通过原子锁与Gate对象来实现的，在没有竞争的情况下，通过原子锁可以速实现加锁及解锁，此外Gate对象是不可重入的，不像Event等(Dispatch Object)及ERESOURCE等可重入的锁(同一个线程可以同时加锁多次不会死锁)。

至于FastMutex为什么要提升IRQL至APC_LEVEL的原因，和文件系统调用FsRtlEnterFileSystem禁APC的原因是一样的，直接目的是防止当前线程被挂起(Suspend)。设想在没有禁止APC的情况下调用ExAcquireFastMutexUnsafe加锁之后线程随时可能被挂起，一旦被挂起的话系统中试图获取该锁的其它线程则只能等待，不管此线程是否高优先级或关键的系统任务。同理可以理解Event，ERESOURCE等为什么也需要禁止APC的原因。

除了FastMutex之外，Windows内核还实现了另外两种Mutex: Regular Mutex及Guarded Mutex。不过从Windows 8开始，GuardedMutext和FastMutex的实现是一样的，二者并无差别。Regular Mutex通过KeInitializeMutex初始化，加锁及放锁是通过KeWaitForXXXObject及KeReleaseMutex来操作的。我们知道 Event也是通过KeWaitForXXXObject来加锁的，但是Regular Mutex的加锁操作却会禁止当前线程的Kernel APC，Event却不会，所以在操作Event之前要显示地进入临界区或禁止APC操作以防止可能的死锁发生。

需要注意的是禁止Kernel APC并不会影响i/o操作，但是FastMutex及GauardedMutex不止是禁止Kernel APC，还会禁止Special APC，这样的话i/o操作是不允许的，因为i/o完成例程是在Special APC中做的。这些细微差别在使用中必须考虑到。