c++ - 为什么 CRITICAL_SECTION 的 OwningThread 成员是 HANDLE 类型，当它表示线程 ID 时？

Question

我正在尝试为 CRITICAL_SECTION 解锁代码添加一些调试检查，我尝试了以下操作:

...
  if (m_pCritSect) {
    ASSERT(m_pCritSect->OwningThread == GetCurrentThreadId());
    LeaveCriticalSection(m_pCritSect);
  }
}

通过调试 CRITICAL_SECTIONS(使用 VS 2005，主要在 WindowsXP 上)我“知道”OwningThread 的值(RTL_CRITICAL_SECTION 结构的成员 winnt 中定义.h) 是持有锁的线程的第 ID 的值。

然而，线程 ID 由 DWORD(unsigned long 的类型定义)值表示，而此变量的类型为 HANDLE( 的类型定义) void*) 需要 reinterpret_cast 用于 使用basetsd.h 中的HandleToULong 宏用于上面的代码可以工作。

即使是 MSDN docs状态:

When the first thread calls the EnterCriticalSection routine, (...) OwningThread becomes the thread ID of the caller.

那么到底为什么要将其定义为 HANDLE？

---

编辑说明:我找到了a statement海报暗示 HANDLE/DWORD-Id 不匹配是某些 Windows 内部结构的已知错误特征。所以也许这里也是这种情况:

GetCurrentThreadId returns a DWORD, which I send up to the kernel in a message. PsLookupThreadByThreadId takes the thread Id in a HANDLE, ... ...

This is a known Windows API bug ("known" in that I talked to the relevant filter manager DEV about this, as it shows up in Filter Manager as well because of the I/O Manager API issue.) As long as you don't have more than a half billion or so threads and processes (they use a single shared handle table) you'll be fine. Maybe by the time that's a real issue, we'll be running something different. [RE: ThreadId to HANDLE for 64 bit?, 08 Aug 08 14:21, Tony Mason]

Answer 1

SDK 中名称以 RTL 或 Rtl 开头的任何标识符都是属于运行时层的代码或声明，是将记录良好的 Winapi 与未记录的 native 操作系统 api 结合起来的粘合剂。 winapi 是一成不变的， native 操作系统随着每个 Windows 版本的发布而发生重大变化。不可避免地，胶水也会发生变化。

winapi 是有文档的层， native 操作系统没有文档。运行时层也没有记录，但随着时间的推移，它的一部分被揭示了。要么是因为它回填了 winapi 中缺少的功能。或者，在这种情况下，因为对于解决问题确实很有用。然而，这样做的一个核心问题是，一旦声明被披露，微软就再也无法更改它。因为这样做会破坏现有的程序，给它的客户带来很大的负担。

可以肯定的是，在以前的 Windows 版本中，ThreadOwner 字段曾经真正拥有线程的句柄。请注意 LockSemaphore 也具有误导性，它实际上是一个自动重置事件。来不及修复它，猫已经不在了。