如何设计支持多线程发信号的单阻塞工作者（Single blocking worker）架构

问题1 可用实现方案 #

你需要的核心是「多次触发信号自动合并为一次唤醒，不会累计多余信号」的机制，可采用的通用实现方式包括：

• 自动重置事件类原语：多数语言标准库都提供对应实现（C#的AutoResetEvent、Swift的DispatchSourceUserDataAdd、Node.js的events模块配合标记都可实现等价逻辑），天然支持多次信号仅保留一个待触发状态，等待一次后自动清空。
• 原子布尔标记 + 阻塞等待原语：用原子类型维护「是否有未处理的任务通知」状态，配合条件变量、信号量等阻塞原语控制唤醒逻辑。
• 上限为1的信号量：将信号量的最大计数设为1，多次释放操作也只会让信号量计数保持为1，不会累计多余信号。

问题2 标准并发API组合实现方案 #

完全可以，以下是跨语言通用的逻辑，完全基于你提到的标准API实现：

1. 定义三个基础组件：lock锁（或原子操作）、最大计数为1的semaphore（初始计数为0）、布尔类型的pendingFlag（初始为false，表示是否有未消费的触发信号）
2. 生产者触发逻辑：
   • 加锁（或用原子交换操作）将pendingFlag设置为true
   • 如果设置前pendingFlag为false，则调用一次semaphore.Release()，否则不做任何操作
3. 工作者执行逻辑：
   • 调用semaphore.Wait()进入阻塞，直到收到信号
   • 加锁（或用原子操作）将pendingFlag设置为false
   • 拉取所有可用任务批量处理，处理完成后回到阻塞步骤
     该逻辑不会累计多余信号，也不需要维护内存任务队列，在C#、Swift、Typescript中都可以用标准库API直接实现。

问题3 为何没有支持一次等待清空所有信号的信号量 #

• 标准信号量的核心设计目标是统计可用资源的数量，语义为「有N个可用资源就允许N次等待通过」，如果一次等待清空所有信号，完全违背了信号量的原始设计定位，会破坏所有依赖信号量计数准确性的场景（比如并发数限制、多worker均匀分配任务等场景）。
• 你需要的「多次触发合并为一次唤醒」语义已经有专门的原语支持，也就是自动重置事件类工具，不需要修改信号量的语义来实现。

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