Delphi Linux平台TEvent.SetEvent方法的线程安全性疑问及跨平台实现差异咨询

Great question! Let's break down both your concerns clearly:

一、这种实现确实存在线程安全风险 #

是的，这个实现会引发竞态条件，导致等待线程错过唤醒信号。举个典型的场景：

• 事件初始处于无信号状态（sem值为0），线程X和Y正在WaitFor该事件而阻塞。
• 线程A调用SetEvent：sem_getvalue返回0，准备执行sem_post。
• A执行sem_post后，sem值变为1，线程X被唤醒并开始执行sem_wait（这是原子操作，会把sem值减回0）。
• 与此同时，线程B调用SetEvent：在X的sem_wait完成前，sem_getvalue返回的是瞬时值1，所以B跳过sem_post。
• 很快X的sem_wait完成，sem值回到0，但线程Y仍在阻塞，而B的SetEvent没有触发信号量递增，导致Y永远无法被唤醒。

问题的核心是：sem_getvalue和sem_post不是原子执行的，中间的线程切换会让sem_getvalue返回的瞬时快照失效，进而导致本该执行的sem_post被跳过。

二、Linux平台添加检查的原因：跨平台语义一致性 #

这个额外检查是为了对齐Windows平台TEvent的行为，尤其是针对手动重置事件（ManualReset=True）：

• 在Windows中，手动重置事件调用SetEvent后，会进入持续有信号状态：所有等待线程都会被唤醒，且事件保持有信号直到调用ResetEvent。哪怕多次调用SetEvent，事件状态也不会改变。
• 但Linux的信号量是计数型的，如果直接每次SetEvent都调用sem_post，会让信号量计数累加。对于手动重置事件来说，这会导致多次WaitFor都能成功（直到计数耗尽），完全不符合Windows下"一次置位，持续有效"的语义。

Delphi的Linux实现试图通过sem_getvalue检查，只在信号量无信号（计数为0）时才调用sem_post，以此模拟Windows手动重置事件的行为。但这种做法牺牲了线程安全性，因为非原子的检查+操作必然会引发竞态条件。

对比Windows和macOS的实现：

• Windows直接调用系统原生SetEvent API，系统内核本身保证了事件对象的线程安全和语义一致性。
• macOS的dispatch_semaphore_signal虽然也是计数型信号量，但Delphi可能在WaitFor逻辑中针对手动重置事件做了特殊处理（比如手动重置事件的WaitFor不会减少信号量计数），所以不需要在SetEvent中添加检查。

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