为什么BCL中没有AutoResetEventSlim？
为什么BCL中没有AutoResetEventSlim类？
可以使用ManualResetEventSlim进行模拟吗？
ManualResetEvent和ManualResetEventSlim都经过精心设计，以便在调用后保持信号状态。 这通常与AutoResetEvent情况截然不同。
AutoResetEvent在使用后立即返回到未信号状态，通常用于不同的场景集。 从AutoResetEvents文档：
通常，当线程需要对资源的独占访问时，可以使用此类。
但是，通常使用ManualResetEvent （和Slim ）用于以下情况：
此通信涉及一个线程必须在其他线程可以继续之前完成的任务。
由于AutoResetEvent最常用于共享资源的多个线程的场景，因此等待时间通常不会非常短。 但是，当您事先知道等待时间非常短时， ManualResetEventSlim才真正有用。 如果您的等待时间不会很短，那么您应该使用ManualResetEvent 。 有关详细信息，请参阅有关MRE和MRES之间差异的文档。
当您的等待时间较长时（这将是AutoResetEvent的正常情况），“苗条”版本实际上更糟糕，因为它恢复使用等待句柄。
我也被这个事实所困扰。 但是，您似乎可以使用具有特殊配置的简单SemaphoreSlim来模拟AutoResteEvent（Slim）：
SemaphoreSlim Lock = new SemaphoreSlim( 1, 1 );
第一个参数（ http://msdn.microsoft.com/en-us/library/dd270891(v=vs.110).aspx ）定义了信号量的初始状态：1表示一个线程可以进入，0表示必须先释放信号量。 所以a = new AutoResetEvent( true )转换为= new SemaphoreSlim( 1, 1 )和a = new AutoResetEvent( false )转换为= new SemaphoreSlim( 0, 1 ) 。
第二个参数定义可以同时进入信号量的最大线程数。 将其设置为1可使其行为类似于AutoResetEvent 。
关于SemaphoreSlim的另一个.WaitAsync()是，使用4.5中的新async / await模式，类已经收到了一个可以等待的.WaitAsync()方法。 因此，在这种情况下不再需要手动创建等待的等待原语。
希望这可以帮助。