为什么BCL没有AutoResetEventSlim？ [英] Why no AutoResetEventSlim in BCL?

问题描述

为什么没有一个 AutoResetEventSlim 类BCL？

Why isn't there an AutoResetEventSlim class in BCL?

可以用它来模拟 ManualResetEventSlim ？

推荐答案

的ManualResetEvent 和 ManualResetEventSlim 都被设计成他们仍然要求后发出信号。这通常是一个非常不同的情况下比的AutoResetEvent 。

ManualResetEvent and ManualResetEventSlim both are designed so that they remained signaled after calling. This is typically for a very different scenario than AutoResetEvent.

的AutoResetEvent 立即返回到unsignaled状态使用后，它通常用于一组不同的场景。从AutoResetEvents文档：

AutoResetEvent immediately returns to the unsignaled state after usage, which is typically used for a different set of scenarios. From AutoResetEvents documentation:

通常情况下，你使用这个类当线程需要独占访问的资源。

Typically, you use this class when threads need exclusive access to a resource.

的ManualResetEvent （和超薄）通常使用，然而，对于这样一个场景：

ManualResetEvent (and Slim) are typically used, however, for a scenario where:

该通信涉及一个任务，一个线程必须完成之前，其他线程才能继续。

this communication concerns a task which one thread must complete before other threads can proceed.

由于的AutoResetEvent 是最常用的场景中有多个线程共享一个资源，等待时间一般不会很短。 ManualResetEventSlim ，但是，真的只打算当你知道，在前进，等待时间很短。如果您的等待时间不会很短，那么你应该使用的ManualResetEvent 代替。查看MRE和MRES之间的差异的文档了解详细信息。

Since AutoResetEvent is most commonly used in scenarios where there are multiple threads sharing a resource, wait times typically would not be extremely short. ManualResetEventSlim, however, is really only intended when you know, in advance, the wait time is very short. If your wait time is not going to be very short, then you should use ManualResetEvent instead. See the documentation on the difference between MRE and MRES for details.

当你的等待时间更长（这将是正常情况下使用的AutoResetEvent ），在苗条的版本实际上是糟糕的，因为这将恢复使用一个等待句柄

When your wait times are longer (which would be the normal scenario with AutoResetEvent), the "slim" version is actually worse, as it reverts to using a wait handle.

这篇关于为什么BCL没有AutoResetEventSlim？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！