如何在其他进程终止时避免WaitForSingleObject在命名信号量上挂起？

Windows内核仅对**互斥量（Mutex）**对象内置了持有进程终止后的自动遗弃处理逻辑：当持有互斥量的进程被强制结束或崩溃退出，内核会自动释放该互斥量，所有等待该互斥量的线程会收到WAIT_ABANDONED返回值，不会无限阻塞。
而信号量、事件等其他内核同步对象没有这套机制：内核无法判断持有信号量的进程终止后，信号量的计数应该修正为多少、是否应该触发等待线程，因此不会做任何自动处理，才会出现WaitForSingleObject(..., INFINITE)永久卡死的问题。
不存在任何信号量的创建参数或配置项可以开启遗弃检测，这是内核层面的对象特性差异，无法通过配置修改。

按改造成本从低到高、可靠性从高到低排序：

方案1：双对象等待，同时监听对端进程存活状态（最推荐） #

这是改造成本最低、可靠性最高的方案，完全不需要改动你现有的信号量同步逻辑，只需要修改等待逻辑即可：

• 双方初始化同步通道时，将自身的进程ID（通过GetCurrentProcessId()获取）写入共享缓冲区的固定预留字段，对端读取到PID后，调用OpenProcess(SYNCHRONIZE, FALSE, 对方PID)获取对端进程的可等待句柄（仅需要SYNCHRONIZE权限即可满足等待需求，不需要高权限）。
• 将原来调用WaitForSingleObject等待信号量的逻辑，替换为WaitForMultipleObjects同时等待2个句柄：一个是原有的读写通知信号量，另一个是刚获取的对端进程句柄，设置为任意对象触发就返回。
  示例代码：

HANDLE waitHandles[2] = { hNotifySemaphore, hPeerProcess };
DWORD waitRet = WaitForMultipleObjects(
    2,
    waitHandles,
    FALSE,
    INFINITE
);
if (waitRet == WAIT_OBJECT_0) {
    // 正常收到通知信号，读取共享缓冲区即可
    ReadSharedBuffer();
} else if (waitRet == WAIT_OBJECT_0 + 1) {
    // 对端进程已终止，立即退出等待，走异常处理逻辑
    HandlePeerCrashError();
} else {
    // 等待失败等其他异常处理
    HandleWaitError(GetLastError());
}

• 注意事项：进程句柄使用完后需要调用CloseHandle释放；检测到对端崩溃后记得重置本地同步对象状态，避免后续对端重启后出现信号量计数错乱的问题。

方案2：替换为互斥量实现同步逻辑 #

如果你的场景中信号量计数固定为1，本质是实现跨进程的二元状态同步，可以调整同步逻辑，用互斥量替代信号量，利用互斥量原生的遗弃检测能力：

• 核心调整：把两个方向的通知逻辑和共享缓冲区的所有权绑定，持有互斥量的一方拥有共享缓冲区的操作权，操作完成后释放互斥量交给对方。
• 当持有互斥量的一方崩溃，等待方会收到WAIT_ABANDONED返回值，立刻从等待中唤醒，不会永久阻塞。
• 缺点：需要重构现有同步状态的流转逻辑，改造成本比方案1高；且互斥量的所有权语义和信号量有差异，需要仔细处理WAIT_ABANDONED场景下的共享缓冲区数据一致性问题（崩溃时缓冲区里的数据可能是未写完的无效数据）。

兜底方案：短超时轮询 #

如果因为特殊限制拿不到对端进程句柄，可以把WaitForSingleObject的超时值从INFINITE改成50~200ms的固定短值，每次等待超时后通过之前拿到的对端PID检查进程是否存活，如果存活就继续等待，否则走异常逻辑。

• 缺点：存在最长等于超时时长的检测延迟，且会持续消耗CPU资源，仅作为没有其他办法时的兜底选择。

内容的提问来源于stack exchange，提问作者user3161924