【研究报告】各操作系统中信号量通知替代

xinze/核心开发

socket通信可行性分析

linux平台可行性分析

1. 结论

（1）各技术路线各场景中发送开销1us~2us之间，变化波动较小。

（2）其他条件不变，只要进行了绑核，通知时间开销均值会有非常明显的降低。例如满负载情况下2000个posix具名信号量，不绑核均值超过157us，绑核后均值降至不到7us。

（3）除system v超时100ms共计2000信号量场景外，所有绑核场景的通知时间开销均值都在个位数us。

（4）作为比较，参考【研究报告】非极速模式性能测试及结果分析，绑核加使用大页情况下传输开销仍在数百us，因此理论上信号量通知替代现有socket通信之后会有提升。（信号量通知测试中没有加入读取共享内存中内容的步骤，实际表现有待验证）

（5）其他条件不变，部分满载场景通知时间开销表现甚至比低负载场景好。一种可能的解释是满负载场景下操作系统换入换出调度更为激进，阻塞进程可被更快唤醒。

2. 技术路线优劣对比

3. linux平台中POSIX具名信号量及system v信号量集进行线程间通知时间开销的统计表

注：
（1）测试场景为一发多收，每个信号量对应一个接收进程且由该进程创建，创建成功后发送进程使用相同的信号量完成通知建立。（这里没有采用所有接收进程使用同一个信号量的原因是，阻塞后被唤醒由操作系统完成，如果接收进程唤醒后再次进入阻塞状态所需时间小于通知发送间隔就会出现重复通知以及配套的通知不到的问题，其中重复通知仅有浪费系统资源的代价，而通知不到的问题会影响及时性与可靠性）

（2）测试中每轮给所有信号量发送一次通知，每轮通知发送间隔均为1s，共计20轮。

（3）低负载通过重启设备实现，同时仅有本用户在使用可保证不受干扰。满负载通过20个进程分别执行二十亿次开平方计算实现，此时通过htop观察到所有CPU核心占用率100%，load average接近20，大于CPU核数12且满载持续时间超过测试所需时间30s以上，可保证通知延迟测试过程中环境一致。

（4）system v信号量集在centos7.9上默认可创建数量为128，每个信号量集一个信号量的情况下随着测试进行无法满足场景要求，需要通过指令去修改系统参数。（当然对于用户来讲，修改系统参数是体验较差且风险不可控的操作，因此非必要尽可能不要去修改系统参数）。POSIX具名信号量当前测试场景下暂时没有触及系统资源限制32000个信号量的烦恼。

MacOS平台可行性分析

1. posix具名信号量和system v信号量集的demo代码在linux平台和MacOS平台是通用的，所以这两个平台可以使用相同的技术方案。

2.值得注意的是system v信号量集方法虽然也支持，但是system v IPC被标注为过时的技术建议使用posix方案，同时MacOS新提供了Mach信号量方法。参考：BSD Overview Mach provides a number of IPC primitives that are not traditionally found in UNIX. See Boundary Crossings for more information on Mach IPC. Some System V primitives are supported, but their use is discouraged in favor of POSIX equivalents.

3. 从mach信号量的介绍中，关注到“被阻塞进程在唤醒后不会立即执行”，这与posix信号量的表现有所区别。（在MACOS平台上，使用mach信号量被阻塞的进程在唤醒后可能需要等待一段时间才能真正开始执行，而使用posix信号量的进程通常会立即执行。）参考： Synchronization Primitives Mach semaphores obey Mesa semantics—that is, when a thread is awakened by a semaphore becoming available, it is not executed immediately. This presents the potential for starvation in multiprocessor situations when the system is under low overall load because other threads could keep downing the semaphore before the just-woken thread gets a chance to run. This is something that you should consider carefully when writing applications with semaphores.

因此建议，在MACOS也使用posix信号量方法，复用linux的技术路线。

Windows平台信号量通知可行性分析

1 结论：

（1）Windows平台与linux和MacOS平台的代码不通用（编译会报错找不到include的库），Windows自行提供了一套接口，原理相通，可在构造阶段通过#ifdef _WINDOWS之类的宏来做区分。

（2）发送时间开销均值个位数us，较为稳定。

（3）除不超时20信号量场景通知时间开销均值在数十us级别外，其余场景通知接收时间开销均值在数百us级别。

2 Windows自带信号量时间开销统计表：

注：
（1）测试场景、方案等与linux测试保持一致。

（2）Windows上信号量通过handle进行管理（文件、进程、线程等都会分配唯一handle），测试过程中没有触及默认系统上限。