41

Why isn't there an AutoResetEventSlim class in BCL?

Can it be simulated using ManualResetEventSlim?

George Duckett
  • 31,770
  • 9
  • 95
  • 162
user629926
  • 1,910
  • 2
  • 18
  • 43

3 Answers3

30

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

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 (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.

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.

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.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 1
    I don't think the different typical use cases say anything about expected wait times at all. In fact, I'd expect less of a wait for "multiple threads sharing the same resource" than for "one thread must complete before other threads can proceed". – relatively_random Mar 07 '22 at 15:42
28

I was bugged by this fact as well. However, it appears that you can simulate an AutoResetEvent(Slim) using a simple SemaphoreSlim with a special configuration:

SemaphoreSlim Lock = new SemaphoreSlim( 1, 1 );

In the constructor, the first parameter defines the initial state of the semaphore: 1 means that one thread may enter, 0 that the semaphore has to be released first. So new AutoResetEvent( true ) translates to new SemaphoreSlim( 1, 1 ) and new AutoResetEvent( false ) translates to new SemaphoreSlim( 0, 1 ) respectively.

The second parameter defines the maximum number of threads that may enter the semaphore concurrently. Setting it to 1 lets it behave like an AutoResetEvent.

One other nice thing about the SemaphoreSlim is that with the new async/await pattern in 4.5 the class has received a .WaitAsync() method which can be awaited. So there is no need to manually create an awaitable wait primitive in this case any more.

Hope this helps.

Lance U. Matthews
  • 15,725
  • 6
  • 48
  • 68
Simon Mattes
  • 4,866
  • 2
  • 33
  • 53
  • 1
    One complication when using the `SemaphoreSlim` as a stand-in for `AutoResetEvent`: trying to release when already at maximum count will throw a `SemaphoreFullException`, unlike setting the event when already set. – relatively_random Mar 07 '22 at 15:45
1

To quote Microsoft's Josh Phillips (original here):

As for AutoResetEventSlim.. is there a scenario for which you need it? Truth be told, creating an AutoResetEvent is quite difficult and the use cases are very limited so we prioritized our efforts elsewhere. If there's a real need for you to have one, I'd love to hear it so we could consider creating one!

To expand on the comment: you can just use a manual event and make sure to always reset it after waiting.

If that small delay between waiting and resetting is causing problems, there's probably a fundamental issue somewhere anyway. For instance, if there are multiple consumers and you should only let one through, maybe an event isn't the right tool for the job and you should consider SemaphoreSlim or even just the raw Monitor.

relatively_random
  • 4,505
  • 1
  • 26
  • 48