为什么 BCL 中没有 AutoResetEventSlim？

Question

为什么 BCL 中没有 AutoResetEventSlim 类？

可以使用ManualResetEventSlim来模拟吗？

Answer 1

ManualResetEvent 和 ManualResetEventSlim 均经过精心设计，以便在调用后保持有信号状态。这通常适用于与 AutoResetEvent 截然不同的场景。

AutoResetEvent 使用后立即返回到无信号状态，这通常用于不同的场景。来自 AutoResetEvents 文档：

通常，当线程需要独占访问资源时，您可以使用此类。

然而，ManualResetEvent（和Slim）通常用于以下场景：

此通信涉及一项任务，一个线程必须先完成该任务，然后其他线程才能继续。

由于 AutoResetEvent 最常用于多个线程共享资源的场景，因此等待时间通常不会非常短。然而，ManualResetEventSlim 实际上仅适用于您提前知道等待时间非常短的情况。如果您的等待时间不会很短，那么您应该使用ManualResetEvent。有关详细信息，请参阅有关MRE 和 MRES 之间的差异的文档。

当您的等待时间较长时（这将是 AutoResetEvent 的正常情况），“精简”版本实际上更糟糕，因为它会恢复为使用等待句柄。

Answer 2

我也被这个事实困扰了。
但是，您似乎可以使用简单的 AutoResetEvent(Slim) "noreferrer">SemaphoreSlim 具有特殊配置：

SemaphoreSlim Lock = new SemaphoreSlim( 1, 1 );

在 构造函数，第一个参数定义了信号量：1表示一个线程可以进入，0表示信号量有要先被释放。因此，new AutoResetEvent( true ) 转换为 new SemaphoreSlim( 1, 1 ) ，而 new AutoResetEvent( false ) 转换为 new SemaphoreSlim( 0, 1) 分别。

第二个参数定义可以同时进入信号量的最大线程数。将其设置为 1 使其行为类似于 AutoResetEvent。

SemaphoreSlim 的另一件好事是，通过 4.5 中新的 async/await 模式，该类收到了 .WaitAsync() 方法 可以等待。因此，在这种情况下不再需要手动创建可等待的等待原语。

希望这有帮助。

Answer 3

引用微软的 Josh Phillips (原始在这里）：

至于AutoResetEventSlim..是否有您需要它的场景？
说实话，创建 AutoResetEvent 非常困难，而且
用例非常有限，因此我们优先考虑其他地方的工作。
如果您确实需要一个，我很想听听，所以我们
可以考虑创建一个！

扩展评论：您可以只使用手动事件，并确保在等待后始终重置它。

如果等待和重置之间的微小延迟导致了问题，那么无论如何都可能存在根本性问题。例如，如果有多个消费者，而您应该只让其中一个通过，那么事件可能不是完成这项工作的正确工具，您应该考虑 SemaphoreSlim 甚至只是原始的 Monitor< /代码>。