在 unix 上使用 semop() 函数，可以提供一个 sem_op =0 的 sembuf 结构。本质上，这意味着调用进程将等待/阻塞，直到信号量的值变为零。在 Windows 中是否有等效的方法来实现这一点？
我试图实现的具体用例是等到读者数量达到零后再让作家写。（是的，这是使用信号量的一种有点非正统的方式；这是因为对阅读器的数量没有限制，因此没有一组受限制的资源，而这正是信号量通常用来管理的）
关于 unix semop 系统调用的文档可以在这里找到： http ://codeidol.com/unix/advanced-programming-in-unix/Interprocess-Communication/-15.8.-Semaphores/
假设您有一个编写器线程，只需让编写器线程吞噬信号量即可。即，WaitForSingleObject无论您将信号量计数初始化为多少次，都可以通过获取信号量。
Windows 信号量从最大值（允许的最大读取器数量）倒计时到零。WaitXxx函数等待一个非零信号量值并递减它，增加信号量（允许等待信号量的其他线程解除阻塞）。不可能以不同的方式等待 Windows 信号量，因此在您的情况下，Windows 信号量可能是同步原语的错误选择。在 Vista/2008 上，您可以使用纤薄的读写锁；如果您需要支持早期版本的 Windows，则必须自己动手。ReleaseSemaphore
我从未见过任何类似于 Win32 API 中的函数。
我认为这样做的方法是调用WaitForSingleObject或类似方法并获得WAIT_OBJECT_0与创建信号量时指定的最大计数相同的次数。然后，您将持有所有可用的“插槽”，等待信号量的任何其他人都会阻塞。
我试图实现的具体用例是等到读者数量达到零后再让作家写。
你能保证在作者写完之前读者数将保持为零吗？
如果是这样，您可以使用手动重置事件对象来实现等效于 SysV“等待零”行为，表示最后一个读取器已完成。保持您自己的（同步）“活跃读者”计数，随着读者完成而递减，然后SetEvent()在该计数为零时向耐心等待的作者发出信号。
如果您不能保证读者会表现良好，那么即使使用 SysV sem，您也将面临一场不愉快的比赛。