如何优雅地等待一个命名对象（如 Mutex）被创建？
在 Windows 系统开发中，跨进程同步是经常遇到的问题，最常见的做法之一是使用命名 Mutex（互斥体）判断另一个进程是否已启动，并借此完成单实例运行和就绪通知。本文基于 Raymond Chen 的文章，结合实际开发经验，深入解析相关技术原理及可选方案。
命名 Mutex 的常规用法与局限
命名 Mutex 在多实例检测、进程互斥等场景非常常见。一般做法如下：
- 程序启动时尝试创建指定名称的 Mutex。
- 若 Mutex 已存在，则说明另一个实例正在运行。
- 若 Mutex 不存在，则当前实例为唯一运行的实例。
此外，有些程序进一步约定：只有当 Mutex 创建成功后，才代表“已就绪，可以接受任务”。于是有了如下问题：
管理程序如何“等待” Mutex 被创建？
很多人希望管理进程能“阻塞式”地等待目标进程的 Mutex 出现，从而避免轮询带来的资源浪费。但 Windows API 没有为“等待一个命名内核对象被创建”提供直接通知机制。
为什么“事件”不能直接解决？
一种常见思路是用“命名事件”实现同步：主程序在准备好后，SetEvent 通知管理程序。但这种设计存在关键隐患：
- 如果主程序异常崩溃，事件对象虽然句柄关闭了，但事件本身不会自动重置信号，下次管理程序启动时会误判“已就绪”。
- Mutex 被释放时会标记“abandoned”，而事件对象无类似自动回滚机制。
举例说明：
- 管理程序启动，等待名为
ReadyEvent的事件对象被 Set。 - 被管理程序启动后 SetEvent。
- 如果程序未执行 ResetEvent 就异常退出，下次启动管理程序就会误以为“已准备好”。
进阶方案：共享内存与自定义信号机制
为了解决异常退出、信号失效等问题，可以引入共享内存协作：
- 创建一个带有版本号、进程PID和启动时间的共享内存区（用命名 Mutex 保护）。
- 管理程序每次启动时检查共享内存记录，如果发现信息不一致（上次进程已退出），则生成新的事件名称并等待之。
- 新实例启动后写入自己的信息并 Set 事件，通知管理程序。
这种方式兼具：
- 异常恢复能力（PID/启动时间唯一标识实例）。
- 动态多实例管理。
- 但实现略为复杂，需要可靠的同步与异常恢复逻辑。
Opportunistic Lock 旁路法
Raymond Chen 还提出一个有趣的思路：借用 Opportunistic Lock（机会锁） 机制。做法是：
- 管理程序打开一个文件并加上机会锁。
- 被管理程序就绪时，以写模式打开该文件，触发锁断裂（lock break），即完成“就绪通知”。
这种做法优雅但实际使用不多，主要适合文件相关的进程间通信。
最正统、健壮的选择：COM 本地服务器
Windows COM 本地服务器本身就是为“进程启动与就绪”场景而生的。调用 CoCreateInstance 时，COM 框架负责：
- 启动本地服务器进程。
- 等待其注册对象（即代表“就绪”）。
- 确保单实例/多实例的精细控制（通过 REGCLS_MULTIPLEUSE/REGCLS_SINGLEUSE）。
这种做法的优势是：
- 不需要手动维护同步状态，系统级支持。
- 支持异常进程恢复。
- 有标准通信接口。
缺点主要在于需要注册 CLSID、开发 COM 接口，门槛相对高，对本地临时用例略显复杂。
社区补充与工程实践
部分工程师提出可以直接通过进程间句柄传递，在被管理进程启动后，用 WM_COPYDATA 或管道回传“就绪”信号，方式灵活，适用于进程关系明确、信任的场景。
举例：
- 管理进程在启动子进程时传递自身窗口句柄。
- 子进程启动并创建 Mutex 后，用
SendMessage（WM_COPYDATA）通知管理进程已准备好。 - 这种设计能规避事件异常和内核对象机制局限，但需自行处理进程边界和句柄有效性。
总结与建议
命名 Mutex 是常用的进程同步工具，但其“就绪通知”能力有限。在涉及进程间启动与信号传递时，建议优先考虑如下顺序：
- 只需判断“已启动”，直接检测 Mutex。
- 需可靠“就绪”信号，考虑事件+共享内存/机会锁。
- 需系统级健壮支持，建议用 COM 本地服务器模型。
- 简单自控场景，可用进程间消息传递。
每种方式都有适用场景和边界，开发时应权衡异常恢复、复杂度与系统兼容性。
参考原文：How can I wait until a named object (say a mutex) is created? 作者：Raymond Chen