問題タブ [manualresetevent]

サンプル アプリケーションに次のコードがあります。

クラスのコンストラクターで、2 つのスレッドを初期化しました。

これらのスレッドによって実行されるメソッドは次のとおりです。

私が直面している問題は、_screenSaverOff.Wait() メソッドを呼び出した後でも「thread2」がブロックされないことです。以下のログエントリ:

ありがとうパワン・ミシュラ

を使用してスレッドプーリングを実装しNSOperationQueueました。に設定maxConcurrentOperationCountしました25。つまり、同時に 25 のスレッドが同時に実行されます。

this を使用してチャンクをサーバーにアップロードしていますNSOperationQueue。したがって、チャンクは最初の 25 スレッドに割り当てられます。がNSOperationQueueいっぱいになったら、チャンク読み取り部分を一時停止し、キューからのスレッドが完了するたびにチャンク部分を再開して、完了しNSOperationQueueたスレッドを置き換えるために新しいスレッドを割り当てます。

私のコード:

では、一時停止と再開の方法はNSOperationQueue? ManualResetEventObjective-C で実装するには?

ManualResetEventSlim州に関する MSDN ドキュメント

このクラスを使用するとManualResetEvent、待機時間が非常に短いと予想される場合よりも優れたパフォーマンスを得ることができます。

「非常に短い」とはどのくらいの期間ですか? ManualResetEventカーネル オブジェクトを使用するメリットが、インスタンス化のオーバーヘッドを上回るのはどの時点ですか?

タイマー付きのWindowsサービスがあります。タイマーは 1 日に約 3 回、ファイルを別の ftp サーバーにアップロードします。タイマーを設定し、ファイルをアップロードしてから、次回の時間を設定します。ファイルをアップロードするために別の ftpserver を追加するまで、これはしばらくの間うまくいきました。その ftpserver にアップロードすると、プロジェクトは manualresetevent.waitone でハングします (フォルダーがアップロードされた場合でも) コードの一部です。さらに必要な場合はお知らせください。

この ftpserver は、私が使用している他の ftpserver とは動作が少し異なります。それが問題の原因かどうかはわかりません。

違いは次のとおりです。非常に大きくなる可能性のあるzipフォルダー（ファイルだけでなく）をアップロードし、アップロード後すぐにそのftpサーバーから移動しています。

(一方、他の ftpserver は ftpserver にファイルを残します)

この問題は、zipfolder が大きくなってから始まったと思います。

私はそれがアップロードされ、そこから削除されることを知っています。

では、アップロードが完了したのに、なぜ waitone でスタックするのでしょうか?

ここで私の endstreamcallback 関数

' EndGetResponseCallback メソッド
は ' BeginGetResponse の呼び出しを完了します。

私はそれが何かをするコールバックであるというタイマーを持っています:

タイマー:

コールバック:

タイマーを停止したいときは、停止機能を呼び出しました：

timerDisposeHandler.WaitOne();停止関数に続くコードの前に破棄が行われることを確認するための使用。

しかし、コールバックの途中で stop 関数が呼び出されると、waitone がすべてスタックすることがあります。

WaitOne がコールバックをスタックしているようですが、なぜそれが起こっているのかわかりません。タイマー コールバックが独自のスレッドで見つからないのですか? 停止機能のスレッドがスタックする必要があるのはなぜですか?

誰かが私に状況を説明し、解決策を教えてくれれば幸いです。