リソースをスレッドの数に割り当てる必要があったため、これらすべてを処理するためにセマフォを使用しました。その後、リソースのプロセス間ロックの場合にセマフォが使用されることに気付きました。私はグーグルでIn-ProcessSemaphoreの実装を見つけてそのクラスを使用しましたが、いくつかの奇妙なバグがあります。
今私の質問は、ドットネットセマフォクラスを使用する必要がありますか?とにかく、プロセス内セマフォを作成して、プロセス間(内部管理)のコストを削減できるのでしょうか。
リソースをスレッドの数に割り当てる必要があったため、これらすべてを処理するためにセマフォを使用しました。その後、リソースのプロセス間ロックの場合にセマフォが使用されることに気付きました。私はグーグルでIn-ProcessSemaphoreの実装を見つけてそのクラスを使用しましたが、いくつかの奇妙なバグがあります。
今私の質問は、ドットネットセマフォクラスを使用する必要がありますか?とにかく、プロセス内セマフォを作成して、プロセス間(内部管理)のコストを削減できるのでしょうか。
Semaphore クラスには、多数のコンストラクターがあります。一部のオーバーロードでは、名前を指定できます。Semaphore インスタンスに名前を付けると、他のプロセスで使用できるシステム レベルのセマフォになります。それが必要ない場合は、他のコンストラクターのいずれかを使用してください。ただし、IIRCにはまだインスタンスに関連付けられたカーネルオブジェクトがあります。
http://msdn.microsoft.com/en-us/library/e1hct27h.aspxを参照してください。
あなたがスレッディングの第一人者ではない場合は、既知の労働者階級に固執することをお勧めします。そうです、タスクに適している場合は、.NET セマフォ クラスに固執してください。
正当な理由 (プロファイラーの結果など) がない限り、コードをマイクロ最適化しないでください。
とはいえ、コード パターンがプロデューサー/コンシューマー パターンのようなものである場合、OS 同期オブジェクトの使用を回避するMonitor クラスを使用した効率的なソリューションがあります。
.NET 4.0 以降では、プロセス境界を越えて待機する必要がない場合は、SemaphoreSlim クラスを使用できます。
ここでは、2 つの間での選択に関する別の議論を示します。