問題タブ [waithandle]

スレッドプールでキューに入れられたときに失敗したワーカーを追跡（カウント）し、すべてのスレッドを終了するためにWaitHandle.WaitAll（）を使用する優れた方法を探しています。

カウンターのインターロックは良いテクニックですか、それとももっと強力な戦略がありますか？

多くの場合があるアプリケーションがあります。それぞれのケースには、多くのマルチページtifファイルがあります。tfファイルをpdfファイルに変換する必要があります。ファイルがたくさんあるので、変換プロセスをスレッド化できると思いました。現在、プロセスを一度に10回の変換（つまり、10回のトレッド）に制限しています。1つの変換が完了すると、別の変換が開始されます。

これは私が使用している現在の設定です。

これを使用すると、WaitHandle.WaitAll（）またはWaitHandle.WaitAny（）配列パラメーターが65の長さを超えてはならないという例外が発生することがあります。このアプローチで何が間違っているのでしょうか。

私は.NETThreadingを読んでいて、 ManualResetEventを使用するいくつかのコードに取り組んでいました。私はインターネット上でたくさんのコードサンプルを見つけました。ただし、WaitHandleのドキュメントを読んだときに、次のことがわかりました。

WaitHandleはDisposeパターンを実装します。管理されていないリソースをクリーンアップするためのファイナライズと破棄の実装を参照してください。

作成したManualResetEventオブジェクトで.Close（）を呼び出すサンプルはなく、pfxteamブログのRecursion and Concurrencyの記事もあります（編集-これには、私が見逃したusingブロックがあります）。これは単なる見落としの例ですか、それとも必要ありませんか？WaitHandleは「オペレーティングシステム固有のオブジェクトをカプセル化する」ため、リソースリークが発生しやすいので不思議です。

JosephとBenAlbahariによるC＃3.0の概要を読んでいるときに、次の段落に出くわしました（673ページ、「待機とパルスによるシグナリング」というタイトルのセクションの最初の段落）

「Monitorクラスは、 WaitとPulseの2つの静的メソッドを介して別のシグナリング構造を提供します。原則として、カスタムフラグとフィールド（ lockステートメントで囲まれています）を使用してシグナリングロジックを自分で記述し、 WaitコマンドとPulseコマンドを導入してCPUの回転を軽減します。この低レベルのアプローチの利点は、Wait、Pulse、およびlockステートメントだけで、 AutoResetEvent、ManualResetEvent、Semaphore、およびWaitHandleの機能を実現できることです。の静的メソッドWaitAllおよびWaitAny。さらに、Wait and Pulse は、すべての待機ハンドルが同じようにチャレンジされる状況で受け入れられる可能性があります。」

私の質問は、最後の文の正しい解釈は何ですか？

• WaitOne（）が特定の待機ハンドルでたまにしか呼び出されない、まともな/多数の待機ハンドルがある状況。
• 適切な/多数の待機ハンドルがあり、特定の待機ハンドルで複数のスレッドがブロックされることはめったにない状況。
• 他の解釈。

また、そのような状況の例と、おそらく他の方法ではなく、待機とパルスを介してそれらがより効率的に処理される方法および/または理由を明らかにしていただければ幸いです。

ありがとうございました！

編集：私はここでオンラインでテキストを見つけました

現在、外部クライアントからの接続を通常どおりリッスンし、接続時にリクエストを処理するサーバータイプのアプリケーションを作成しています。

現時点では、私の実装では、クライアントが接続するたびにスレッドのペアが作成されます。1 つのスレッドはソケットから要求を読み取ってキューに追加し、2 つ目のスレッドはキューから要求を読み取って処理します。

基本的に、これらのスレッドをすべて持つのはやり過ぎだと思うかどうか、そして重要なことに、このアプローチが問題を引き起こすかどうかについての意見を探しています.

ほとんどの場合、これらのスレッドはアイドル状態になることに注意することが重要です。私は両方のスレッドで待機ハンドル (ManualResetEvent) を使用しています。リーダー スレッドは、メッセージが利用可能になるまで待機し、利用可能な場合はそれを読み取り、プロセス スレッドのキューにダンプします。Process スレッドは、メッセージがキューにあることをリーダーが通知するまで待機します (ここでも、待機ハンドルを使用します)。特定のクライアントが実際にサーバーを攻撃していない限り、これらのスレッドは待機状態になります。これは費用がかかりますか？

私は少しのテストを終えました.1,000台のクライアントが絶えずしつこく接続されていました-サーバー(つまり、2,000以上のスレッド)で、非常にうまく対処しているように見えました.

TcpClientCompactFramework2.0アプリケーションの1つでを使用しています。TCPサーバーから情報を受け取りたい。

Compact Frameworkは「大規模な」フレームワークのタイムアウトメカニズムをサポートしていないため、独自のタイムアウト機能を実装しようとしています。基本的に、私は次のことをしたいと思います。

を呼び出したいSetのですがIAsyncResult.AsyncWaitHandle、そのようなメソッドがなく、どの実装にキャストするのかわかりません。

待機ハンドルを設定するにはどうすればよいですか？それとも、を呼び出すことで自動的に設定されEndReadますか？ドキュメントは、私が自分自身を呼び出さなければならないことを示唆していますSet...

助けてくれてありがとう！

UPDATE
呼び出し時に待機ハンドルが自動的に設定されているようEndReadですが、ドキュメントにはありません。誰かがこれを確認できますか？

UPDATE2サンプルコードを
書きました。client.BeginReadもちろん、BeginReadと呼ばれていNetworkStreamます...

NamedPipeServerStream を使用して、2 つのプロセス間で通信しています。パイプを初期化して接続するコードは次のとおりです。

しかし、それは決して待っているようには見えません。次の例外が常に発生します。

System.InvalidOperationException: パイプはまだ接続されていません。System.IO.Pipes.PipeStream.CheckWriteOperations() で System.IO.Pipes.PipeStream.WriteByte(Byte 値) で PeachesObjectVisualizer.Visualizer.Show (IDialogVisualizerService windowService、IVisualizerObjectProvider objectProvider) で

待機が戻った後、すべての準備が整うはずだと思います。

pipeServer.WaitForConnection() を使用すると、すべて正常に動作しますが、パイプが接続されていない場合にアプリケーションをハングさせることはできません。

私のアプリケーションは、複数のインスタンスThreadPool.QueueUserWorkItemを介して追跡するさまざまな小さなワーカースレッドの負荷を生成します。ManualResetEventこのメソッドを使用して、WaitHandle.WaitAllこれらのスレッドが完了するまでアプリケーションが閉じないようにブロックします。

これまで問題が発生したことはありませんが、アプリケーションの負荷が高くなる、つまりスレッドが作成されるようになると、次の例外が発生し始めます。

WaitHandles must be less than or equal to 64 - missing documentation

これに対する最良の代替ソリューションは何ですか？

コードスニペット

回避策

私はいくつかのマルチスレッドを行っており、AutoResetEvents と ManualResetEvents を使用してメインループを制御しています。スレッドを「破棄」するとき、これらのシグナルも破棄する必要があることは明らかです。

しかし、Waithandles を破棄するさまざまな方法を見ましたが、どれが正しいかわかりません。

バージョン 1

バージョン 2

バージョン 3

更新のために 3 秒ごとに ajax を介してポーリングするブラウザーを含むアーキテクチャがあり、それをlong-pollingに変更したいと思います。

1, 2.. {n} 個のクライアントがロング ポーリングを行い、更新を待機し、待機しているクライアントに戻るように通知するためにサーバーで何かが発生するようにしたいと考えています。最初に考えたのは を使用することでしたEventWaitHandle。1 つのクライアントをサポートするだけであれば、これは簡単に実行できます。クライアントをブロックするだけで、おそらくタイムアウトで、そうではないかもしれません。いずれにせよ、サポートできるのは 1 つのクライアントのみであり (待機中のスレッドは 1 つしか起動しないため)、n 個のクライアントが必要です。AutoResetEvent WaitHandleWaitOneAutoResetEvent

を使用する必要があると確信していますが、それをいつ呼び出すかはわかりません(スレッドを起動するとき)。と の間の任意の量だけを使用する必要がありますか?ManualResetEvent WaitHandleResetSetThread.SleepSetReset

疑似コードでは、ウェイク ロジックは次のようになります。

• 得るManualResetEventWaitHandle
• 電話Set
• 新しいリクエストが吹き飛ばされるのを防ぎながら、待機中のすべてのクライアントが目覚めたことを確認します
• Reset待機中のすべてのクライアントが更新を受信したので、今すぐ呼び出します

私が苦労しているのはその3行目です。現在LastTxID、クライアント/サーバーが維持し、潜在的に2つの待機ハンドルを使用するという考えを投げかけています。ただし、この実装に夢中になる前に、ここでフィードバックを取得して、ウェイク ロジックがどのように実装されるかを確認したかったのです。

編集：IISを微調整するか、WCFまたはその他のソリューションを介してホスティングすることにより、最大同時ユーザー数を把握することに関連する問題があると仮定します。ウェイクアップ ロジックだけに注目したいと思います。