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

问题描述

为什么 BCL 中没有 AutoResetEventSlim 类?

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 使用后立即返回无信号状态，这通常用于不同的场景集.来自 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(和 Slim)通常用于以下场景:

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 的正常情况)，slim"版本实际上更糟，因为它恢复使用等待句柄.

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屋！