Why no AutoResetEventSlim in BCL?

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.

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.