在 .Set 之后直接在 EventWaitHandle 上调用 .Close (.Dispose) 是否安全？答案

【问题标题】：Is it safe to call .Close (.Dispose) on an EventWaitHandle directly after .Set?在 .Set 之后直接在 EventWaitHandle 上调用 .Close (.Dispose) 是否安全？
【发布时间】：2015-11-23 10:55:15
【问题描述】：

我有一个线程正在等待 EventWaitHandle (AutoResetEvent)：

AutoResetEvent.WaitOne();

我有另一个线程指示第一个线程继续

AutoResetEvent.Set();
AutoResetEvent.Close();

在.Set之后直接调用.Close是否安全，也就是说在AutoResetEvent被释放之前，是否保证等待线程已经继续？

【问题讨论】：

docs for Close 说：“一旦调用此方法，对当前实例的引用将导致未定义的行为。” 无论是对它的新引用，还是对现有实例的引用，例如因为您对WaitOne 的电话没有得到澄清。但我不想尝试...为什么不从等待的人那里关闭/处理它？
因为等待是可选的，所以如果等待没有完成，它就不会被释放......

标签： c# multithreading waithandle event-wait-handle

【解决方案1】：

是的，如果事情完全按照您的问题中描述的那样进行是安全的。如果您知道在您调用 set 时所有线程都已经在等待，那么这些线程将收到信号并且一切都会好起来，因为所有等待的线程都保证在 set 调用返回之前被释放。

但是，如果您由于某种原因遇到竞争并调用 set 并在线程开始等待之前关闭，则在尝试等待时会出现异常。所以在实践中你最好避免这种模式。恕我直言

【讨论】：

我认为你永远不会知道线程正在等待。它们可以在进入等待之前被取消调度 1 条指令，而其他线程无法判断。
感谢您的回复。所以我放弃了这种模式。我找到了一个 AutoResetEvent 的托管实现，我可能会用那个来试试运气：codeproject.com/Articles/244638/Managed-Thread-Synchronization
@usr 没错，这就是为什么我认为这是一个糟糕的模式。我对这里的场景了解不多，无法推荐其他一些解决方案，但是可以实现一些简单的线程安全倒计时，其中线程信号和关闭句柄检查在关闭句柄之前计数，以确保所有消费者都完成了他们的任务.或者只是反向依赖..