.net 在发出信号后处理EventWaitHandle（）是否安全？

我有一种情况，我正在创建大量的

IDisposable

对象，每个对象封装一个

EventWaitHandle

实例，以便我的应用程序的各个感兴趣的部分可以等待它们。此实例的所有者对象之外的任何代码都无法直接访问。它只能通过包装器调用间接访问

一旦一个对象发出完成的信号，它就不再有用了，因此它将由中央管理器对象处理，并从其引用列表中抛出

现在的问题是，如何处理封装的

EventWaitHandle

？当然，为了防止我的应用程序泄露操作系统句柄，也应该尽快处理它

但是，在事件的所有者对象发出信号后，立即同步执行该操作安全吗？如果仍有线程等待释放（即在调用

WaitOne（）

时阻塞），会发生什么情况

---

这里推荐的方法是什么？

我想是时候用我自己的发现来结束这一过程了

我在文档中找不到任何直接的指导方针，但决定遵循我从陈雷蒙的博客中提取的信息。在他的帖子中（我忘记了确切的链接），他提到Win32 API规则规定事件句柄必须在等待期间保持有效。在非托管世界中，这意味着至少一个事件句柄必须保持打开状态

AFAIU、.NET的实现在后台使用Win32 API，每个EventWaitHandle实例对应一个单独的非托管事件。当EventWaitHandle.Dispose（）关闭底层非托管事件的唯一句柄时，这实际上会使事件实例无效

简言之，正确的方法似乎是构建一个并行的基础设施，通过它，事件发布者可以通知潜在的侦听器事件将很快消失。然后，发布者必须等待所有侦听器“取消订阅”（即停止等待），然后才能继续处理（）事件实例

---

这需要大量的簿记，但归根结底，这似乎是正确的。希望这也能帮助其他人解决问题。

您确定当您发出信号时，所有等待事件的线程当前都在等待事件吗？或者某些线程可能在开始等待事件之前就处于某个位置，但还没有等待事件发生吗？@Lasse:当然，在多线程应用程序中，任何事情都可能发生。：）但就我的对象而言，它们的WaitOne（）包装器是原子的。它要么进入等待，要么立即返回。后者不是问题，前者是（或者至少在我看来可能是）。