AutoResetEventSlimBCLにクラスがないのはなぜですか?
を使用してシミュレーションできますManualResetEventSlimか?
AutoResetEventSlimBCLにクラスがないのはなぜですか?
を使用してシミュレーションできますManualResetEventSlimか?
ManualResetEventどちらも、ManualResetEventSlim電話をかけた後も信号が届くように設計されています。これは通常、とは非常に異なるシナリオの場合AutoResetEventです。
AutoResetEvent使用後すぐに信号のない状態に戻ります。これは通常、さまざまなシナリオのセットで使用されます。AutoResetEventsのドキュメントから:
通常、このクラスは、スレッドがリソースへの排他的アクセスを必要とする場合に使用します。
ManualResetEvent(およびSlim)は通常、次のようなシナリオで使用されます。
この通信は、他のスレッドが続行する前に1つのスレッドが完了しなければならないタスクに関係します。
AutoResetEventリソースを共有する複数のスレッドが存在するシナリオで最も一般的に使用されるため、待機時間は通常、極端に短くなることはありません 。ManualResetEventSlimただし、実際には、待機時間が非常に短いことが事前にわかっている場合にのみ意図されています。待ち時間がそれほど短くならない場合は、ManualResetEvent代わりに使用する必要があります。詳細については、 MREとMRESの違いに関するドキュメントを参照してください。
待機時間が長くなると(これはの通常のシナリオですAutoResetEvent)、「スリム」バージョンは待機ハンドルの使用に戻るため、実際には悪化します。
私もこの事実に悩まされていました。ただし、特別な構成AutoResetEvent(Slim)で単純なを使用してシミュレートできるようです。SemaphoreSlim
SemaphoreSlim Lock = new SemaphoreSlim( 1, 1 );
コンストラクターでは、最初のパラメーターはセマフォの初期状態を定義します。1つまり、1つのスレッドが入る可能性があり0、セマフォを最初に解放する必要があります。したがって、それぞれnew AutoResetEvent( true )に変換しnew SemaphoreSlim( 1, 1 )、にnew AutoResetEvent( false )変換しnew SemaphoreSlim( 0, 1 )ます。
2番目のパラメーターは、セマフォに同時に入ることができるスレッドの最大数を定義します。1のように動作するように設定しますAutoResetEvent。
のもう1つの優れた点は、4.5のSemaphoreSlim新しいasync/awaitパターンで、クラスが待機可能な.WaitAsync()メソッドを受け取ったことです。したがって、この場合、待機可能な待機プリミティブを手動で作成する必要はありません。
お役に立てれば。