winapi - Win32 PulseEvent() 函数的替代方法是什么？

Question

Win32 API PulseEvent() 函数 (kernel32.dll) 的文档指出该函数“...不可靠，不应由新应用程序使用。相反，使用条件变量”。但是，条件变量不能像(命名)事件那样跨流程边界使用。

我有一个跨进程、跨运行时( native 和托管代码)的场景，其中单个生产者偶尔会有一些有趣的事情要让零个或更多消费者知道。现在，当生产者需要告知某些信息时，使用此 PulseEvent 函数会使用一个众所周知的命名事件(并设置为有信号状态)。零个或多个使用者等待该事件 (WaitForSingleObject()) 并执行响应操作。在我的场景中不需要双向通信，生产者不需要知道事件是否有任何监听器，也不需要知道事件是否已成功执行。另一方面，我不希望任何消费者永远错过任何事件。换句话说，系统需要完全可靠——但生产者不需要知道情况是否如此。该场景可以被视为“时钟自动收录器”——即生产者提供半规则信号供零个或多个消费者进行计数。所有消费者必须在任何给定时间段内拥有正确的计数。不允许消费者进行轮询(性能原因)。滚动条只有几毫秒(大约 20 毫秒，但并不完全规则)。

Raymen Chen(旧新事物)has a blog post指出 PulseEvent() 函数的“根本缺陷”性质，但我没有看到 Chen 或发布的评论可以替代我的场景。

谁能推荐一个吗？

请记住，IPC 信号必须跨越机器上的进程边界，而不仅仅是线程。该解决方案需要具有高性能，因为消费者必须能够在每个事件发生后 10 毫秒内采取行动。

Answer 1

我认为您将需要一些更复杂的东西来达到您的可靠性目标。

我对你的问题的理解是，你有一个生产者和未知数量的消费者，所有这些都是不同的进程。每个消费者都不会错过任何事件。

我想要更多关于错过事件意味着什么的说明。

i) 如果消费者开始运行并在等待您的通知方法之前到达，并且发生了事件，即使在发送通知时尚未完全准备好，它是否应该处理该事件？ (即消费者何时被视为活跃？何时启动或何时处理其第一个事件)

ii) 同样，如果消费者正在处理一个事件，并且等待下一个通知的代码尚未开始等待(我假设 Wait -> Process -> Loop to Wait 代码结构)那么它应该知道在循环时发生了另一个事件吗？

我假设 i) 是“不是真的”，因为它是进程启动和“准备好”之间的竞争，而 ii) 是"is"；也就是说，一旦消费者存在，每个消费者的通知就会有效地排队，并且每个消费者都可以消费在其事件期间产生的所有事件，并且不会跳过任何事件。

因此，您所追求的是能够向一组消费者发送通知流，其中保证消费者对该流中的所有通知执行操作，从它作用于第一个通知的点到作用于第一个通知的点它关闭了。即，如果生产者生成以下通知流

1 2 3 4 5 6 7 8 9 0

消费者a)启动并处理3，它也应该处理4-0

如果消费者 b) 启动并处理 5，但在 9 之后关闭，那么它应该处理 5,6,7,8,9

如果消费者 c) 在通知开始时正在运行，它应该处理 1-0

等等

简单地脉冲事件是行不通的。如果在事件发出脉冲时消费者没有主动等待事件，那么它将错过该事件，因此如果事件产生的速度快于我们再次循环等待事件的速度，我们就会失败。

使用信号量也不会起作用，就好像一个消费者比另一个消费者运行得更快，以至于它可以在另一个消费者完成处理之前循环到信号量调用，并且如果在这段时间内有另一个通知，那么一个消费者可以处理另一个通知事件不止一次，人们可能会错过一次。也就是说，您可以释放 3 个线程(如果生产者知道有 3 个消费者)，但您无法确保每个消费者仅被释放一次。

共享内存中的事件环形缓冲区(滴答计数)，每个消费者都知道它上次处理的事件的值，并且通过脉冲事件向消费者发出警报，这应该以某些消费者不同步为代价。有时有蜱虫；也就是说，如果他们错过了一次，下次他们受到脉冲时就会 catch 。只要环形缓冲区足够大，以便所有消费者都可以在生产者在缓冲区中循环之前处理事件，就应该没问题。

在上面的示例中，如果消费者 d 错过了事件 4 的脉冲，因为它当时没有等待其事件，然后它进入等待状态，它将在事件 5 产生时被唤醒，因为它是最后一次处理的计数为 3，它将处理 4 和 5，然后循环回事件...

如果这还不够好，那么我建议类似 PGM通过套接字为您提供可靠的多播；这样做的好处是您可以将消费者转移到不同的机器上......