NTSYNC 内核实现：Windows 同步原语的原生路径设计

在 Linux 系统上运行 Windows 游戏时，同步原语的模拟一直是性能瓶颈所在。NTSYNC 驱动作为 Linux 内核的一部分，通过在内核空间直接实现 Windows NT 同步语义，为 Wine 和 Proton 提供了一条绕过用户态转换层的原生路径。这一设计的核心价值在于将同步操作从复杂的用户态模拟逻辑下沉到内核级别，从而获得可预测的延迟和确定性信号传递。

问题的本质：用户态模拟的困境

传统的 Wine 兼容性层在处理 Windows 同步原语时，面临两个核心挑战。首先，Windows 的信号量、互斥锁和事件在语义上与 Linux 的 futex 存在差异，需要在用户态进行复杂的转换。以信号量为例，Windows 语义要求计数器非零时才被视为有信号状态，而 Linux futex 的等待模型则依赖不同的状态约定。这种语义映射不可避免地引入额外的状态检查和转换逻辑。

其次，在高频同步场景下 —— 例如游戏引擎中常见的多线程渲染流水线 —— 用户态与内核态之间的上下文切换成本变得尤为显著。每一次 NtWaitForMultipleObjects 调用都需要经历系统调用、参数验证、语义转换、内核调用这一完整链路，而一个典型的游戏帧可能涉及数百次同步操作，累计的性能损耗不容忽视。

NTSYNC 驱动的设计哲学正是针对这一困境：既然语义转换无法在用户态完美复现，不如将必要的语义差异直接实现在内核中，让 Wine/Proton 能够通过原生接口直接操作这些同步对象，而无需在每次调用时重新构建语义等价物。

三大同步原语的内核建模

NTSYNC 驱动在内核中创建了三种同步对象类型，分别对应 Windows NT 的信号量、互斥锁和事件。这三种对象共享一套统一的内部表示框架，同时保留了各自独特的语义特性。

信号量对象是最接近 Linux 原有概念的 Windows 同步原语。它持有一个 32 位的动态计数器和一个 32 位的静态最大值。驱动将信号量视为有信号状态的条件是计数器非零，每当一次等待成功满足时计数器减一。这种语义与 Windows NtCreateSemaphore 的行为完全一致：在创建时指定初始计数和最大计数，等待操作原子性地递减计数直到为零，释放操作则将计数递增并唤醒等待者。

互斥锁对象的实现则引入了更复杂的拥有权语义。Windows 互斥锁与 Linux mutex 的根本区别在于递归计数机制：一个线程可以多次进入同一个互斥锁，每次进入增加递归计数，每次离开递减计数，直到计数归零才真正释放。NTSYNC 驱动在内核中维护一个 32 位的 volatile 递归计数和一个同样宽度的拥有者标识符。当拥有者为零时互斥锁被视为有信号状态；每次等待满足时递归计数递增并设置新的拥有者，每次解锁时递归计数递减，如果归零则标记为无主状态并唤醒等待者。

互斥锁还引入了被遗弃（abandoned）状态的概念。当一个互斥锁的拥有者线程异常终止而未正确释放互斥锁时，该互斥锁被标记为被遗弃状态。此时任何后续等待该互斥锁的线程将收到 EOWNERDEAD 错误，但这被视为一种特殊的成功 —— 线程获得了互斥锁的所有权并将其重置为初始状态。这一语义在 Windows 编程中用于检测线程意外终止的场景，NTSYNC 通过 NTSYNC_IOC_MUTEX_KILL ioctl 显式通知驱动的拥有者死亡状态，而非依赖线程死亡自动检测。

事件对象分为自动重置和手动重置两种类型，这一区分在游戏引擎编程中极为常见。自动重置事件在被等待满足后会自动重置为无信号状态，通常用于单个工作线程的唤醒通知；手动重置事件则需要显式调用重置操作才会变为无信号状态，适用于广播场景。NTSYNC 驱动为事件维护一个布尔状态值，并区分事件类型。自动重置事件在等待成功满足时被原子性地重置，而手动重置事件则保持其信号状态直到显式重置。

设备节点与实例隔离

NTSYNC 驱动在 /dev/ntsync 路径上创建一个字符设备。驱动文档明确指出，每个在设备上打开的文件描述符代表一个独立的实例，预期用于支撑一个独立的 NT 虚拟机实例。这意味着通过一个设备实例创建的对象只能与同一实例中的其他对象配合使用 —— 跨实例的同步操作在设计层面就是被禁止的。

这种隔离设计反映了 Windows NT 与 Linux 在进程模型上的根本差异。在 Windows 系统中，同步对象可以跨进程边界共享，进程间通过命名对象或继承句柄传递同步对象引用。而 NTSYNC 的设计假设是 Wine 进程内部管理自己的同步对象空间，不需要也不应该支持跨进程的同步原语共享。对于 Wine/Proton 而言，这意味着每个被模拟的 Windows 进程对应一个 NTSYNC 实例，内部所有同步操作都在该实例的上下文中完成。

ioctl API 的结构化设计

NTSYNC 驱动的用户空间接口完全基于 ioctl 操作，这是一种在 Linux 中向内核传递控制命令的标准机制。驱动定义了四组核心数据结构，分别用于描述信号量参数、互斥锁参数、事件参数和等待操作参数。

信号量创建 ioctl NTSYNC_IOC_CREATE_SEM 接收一个包含初始计数和最大计数的结构体。如果初始计数大于最大计数，操作将以 EINVAL 失败。成功时返回一个新的文件描述符，该描述符代表新创建的信号量对象。这种通过 ioctl 返回文件描述符的设计使得同步对象可以像文件一样参与文件描述符的继承、传递和关闭语义。

互斥锁创建 ioctl NTSYNC_IOC_CREATE_MUTEX 接收包含初始递归计数和初始拥有者的结构体。验证规则要求：如果拥有者非零则递归计数必须为零，如果递归计数非零则拥有者必须为零，两者都为非零或都为零都是无效状态。这一规则确保互斥锁在创建时处于一个明确定义的状态 —— 要么是有拥有者但不允许多次进入，要么是无主状态但允许首次获取。

事件创建 ioctl NTSYNC_IOC_CREATE_EVENT 接收包含初始信号状态和事件类型的结构体。自动重置与手动重置的区分通过 manual 字段的非零值指定。成功创建后返回事件对象文件描述符。

在对象操作层面，信号量提供 NTSYNC_IOC_SEM_POST 用于释放信号量，增加计数并可能唤醒等待者；互斥锁提供 NTSYNC_IOC_MUTEX_UNLOCK 用于释放互斥锁递减递归计数；事件提供 NTSYNC_IOC_SET_EVENT、NTSYNC_IOC_RESET_EVENT 和 NTSYNC_IOC_PULSE_EVENT 分别用于设置为信号状态、重置为无信号状态、以及原子性地执行一次脉冲操作 —— 唤醒所有等待者后立即重置。

每个对象还支持 NTSYNC_IOC_READ_* 系列 ioctl 用于查询对象当前状态。这些查询操作在驱动内部通过对象锁保护，确保读取到的状态值是一致的。

等待操作：原子性获取与多对象同步

NTSYNC 驱动的核心能力在于其原子性等待操作，这是实现确定性信号传递的关键。驱动提供两种等待模式：NTSYNC_IOC_WAIT_ANY 等待任意一个对象变为有信号状态并获取它，NTSYNC_IOC_WAIT_ALL 等待所有指定对象同时变为有信号状态并同时获取它们。

等待操作的参数结构 ntsync_wait_args 包含了完整的同步控制能力。timeout 字段以纳秒为单位指定绝对超时时间，支持 MONOTONIC 或 REALTIME 两种时钟源选择。objs 字段指向待等待对象文件描述符数组，count 字段指定数组长度，最大值受 NTSYNC_MAX_WAIT_COUNT 限制。当任何一个对象变为有信号状态时，WAIT_ANY 操作成功获取该对象并立即返回，index 字段返回被获取对象在数组中的索引。如果超时则返回 ETIMEDOUT。

对于互斥锁的等待，参数中的 owner 字段指定了尝试获取互斥锁的拥有者标识。驱动的语义要求：如果互斥锁当前无主，或者当前拥有者与请求的 owner 匹配，则互斥锁被视为有信号状态。获取操作会将递归计数加一并设置新的拥有者。如果两个不同的 owner 标识同时等待同一个互斥锁，只有一个会成功获取 —— 这与 Windows 的互斥锁语义完全一致。

WAIT_ALL 操作则实现了一种更复杂的同步模式：只有当所有指定对象同时处于有信号状态时，等待才会完成并原子性地获取所有对象。在等待期间，任何对象的信号状态可能发生变化 —— 被获取或被释放 —— 驱动会跟踪这种状态变化，只有当所有对象在某一时刻同时满足有信号条件时，操作才会继续。这种全部等待语义在游戏引擎中用于实现复杂的同步依赖图，例如等待多个资源加载完成后才开始渲染。

驱动还支持一个称为 “alert” 的额外事件机制。通过 alert 参数指定一个额外的事件对象，当该 alert 事件被置为信号状态时，等待操作会提前终止。这提供了一种取消等待的能力，常用于实现超时取消、线程中断或动态取消等场景。

零拷贝信号传递的实现要点

从性能角度审视，NTSYNC 驱动的核心价值在于实现真正的零拷贝信号传递。传统用户态模拟方案在每次同步操作时都需要将线程状态信息拷贝到用户空间，由用户态代码进行语义转换后再决定是否需要再次发起系统调用。NTSYNC 驱动的设计则将等待队列直接实现在内核中，线程进入等待状态时直接被放入内核等待队列，而不是在用户态维护代理对象。

具体而言，当用户态代码调用 NTSYNC_IOC_WAIT_ANY 时，驱动会首先检查所有指定对象的信号状态。如果任何对象已处于有信号状态，操作立即返回而不进入睡眠。如果所有对象都处于无信号状态，驱动将当前线程挂起，放入所有对象的内核等待队列中。这一挂起操作完全在内核空间完成，不需要返回用户态再重新调度。

当信号量被释放、互斥锁被解锁或事件被设置时，驱动遍历相关对象的等待队列，选择合适的等待者唤醒。由于等待队列直接位于内核对象结构中，唤醒操作可以直接将线程从睡眠状态移出并放入可运行队列，无需经过任何用户态中介。这种直接从内核等待队列到线程调度的路径是零拷贝信号传递的核心含义 —— 信号状态的变化直接反映在调度器的可运行队列中，中间没有任何用户态处理环节。

对于 WAIT_ALL 操作，零拷贝语义体现得更为明显。驱动的实现确保只有在所有对象同时可获取时，操作才会完成并原子性地返回。这个原子性保证由内核的锁机制提供，不需要用户态协调。如果在等待期间有其他线程改变了某个对象的状态，驱动能够立即检测到这一变化并调整等待条件 —— 这一切都在内核空间中完成，用户态代码只需等待操作返回。

弃用警告与设计边界

NTSYNC 驱动文档明确标注其设计用途为 “兼容性工具”，不建议用于通用同步场景。驱动明确指出，应该使用通用的、通用性更强的接口如 futex 和 poll 作为替代。NTSYNC 的存在理由完全依赖于 Windows 兼容性的需求 —— 它是为了让用户态 NT 模拟器能够高效运行而专门设计的，不应被视为通用同步原语的安全替代品。

这种设计边界体现了 Linux 内核的一贯哲学：为特定场景提供必要的功能，但不引入不必要的复杂性。NTSYNC 通过在内核中精确复刻 Windows NT 同步语义，解决了 Wine/Proton 的性能问题，同时避免了将这种专有语义扩散到其他应用场景的风险。

资料来源：Linux 内核文档 NT synchronization primitive driver，Patchew 补丁系列 v6 NT synchronization primitive driver。

systems