Nothing Is Secret

ERESOURCE加锁函数

最常用的加锁函数只有两个：

  • ExAcquireResourceExclusiveLite：试图获取排它锁
  • ExAcquireResourceSharedLite：试图获取共享锁

除此之外，针对共享锁的获取，还有另外两个函数：

  • ExAcquireSharedStarveExclusive：可以早于等待中的排它请求者
  • ExAcquireSharedWaitForExclusive：不能早于排它的请求者

二者都是试图获取共享锁，和ExAcquireResourceSharedLite只是有些微的小差别。但这两个函数使用的并不多，只限于少见的特殊情况：

ERESOURCE本身是可以重入的，如果当前线程已经获得此锁的话，若再次试图获取，ExAcquireResourceSharedLite将会直接准予此请求，但ExAcquireSharedWaitForExclusive则不会，一定要等到此锁等待列表中所有的排它锁的请求者完成之后才会准予当前调用者。当然如果当前线程之前所获得的ERESOURCE锁是排它锁的话，将会直接准予通行，不然会导致死锁发生。

ExAcquireSharedStarveExclusive和ExAcquireResourceSharedLite的差别只在一点：若已是共享锁状态，ExAcquireSharedStarveExclusive将忽略排它锁等待列表中的所有请求者，直接准予当前线程，以尽可能的减少当前线程的等待时间。

KEVENT,ERESOURCE及Thread Boost

在唤醒KEVENT时，函数KeSetEvent的第二个参数（KPRIORITY Increment）是用来临时提高被唤醒线程的调试优先级的，此举可以让睡眠在此KEVENT上的线程尽快得到处理以提高系统整体性能。

同样ERESOURCE也有类似的机制，在放锁时也会调高等待列表中处于饥饿状态的线程的优先级。

不过除此之外，ERESOURCE还有一种反向的Boost机制，即让等待者在试图获取锁时调高此锁当前拥有者线程的调度优先级，以加快属主线程的处理并尽可能早的释放锁资源。

反向操作却有可能遭遇这样一个问题：作为锁拥有者的线程未必是同步的，很有可能在获取ERESOURCE锁之后就因为异步处理事件（如Workitem，异步I/O请求）在不释放锁的情况下就退出（锁的释放将由异步事件来做），在此情况下ERESOURCE的属主线程指针就变成非法的了。为此Windows内核提供了一种机制来阻止问题的发生：线程等结构体一般都是至少8字节对齐的（最后3位均为0），通过将最后两位设为1的方式（｜0x03）来甄别此指针数据是用户自己所指定的还是默认的系统线程，以此来避免访问已经释放的内存。

从Win7之后，FastFat及Ntfs都有对ERESOURCE的OwnerThread的处理，主要是异步的Noncached i/o事件的处理，其目的就是处理线程在获取ERESOURCE之后退出的情况。