2

TPL と custom を使用すると、奇妙な動作が発生しますLimitedConcurrencyLevelTaskScheduler。基本的に、いくつかの行を含む入力ファイルがあります。各行を読み取って解析し、そのデータを処理する必要があります。処理後、出力ファイルの入力ファイルと同じ位置に書き戻す出力文字列を取得しました。現時点では、入力行を読み取り、文字列と各行の行番号を渡す計算タスク (計算を実行して出力文字列をバッファーに書き込む) を作成し、ダンプするスプーリング タスクを作成するディスパッチャー タスクを作成しています。定期的にバッファをファイルに保存し、すべてのタスクが終了するのを待ちます。

LimitedConcurrencyLevelTaskScheduler実行中のスレッドの実際の数を制限する必要があるため、を使用しています。

問題は、実行中のスレッドの数が非常に少ない場合 (1 または 2)、タスクが行番号順に (最初の行から最終行へ) スケジュールされますが、逆の順序で (最終行から最初へ) 実行されるようです。スプーリングスレッドは最後までバッファをダンプできないため(行を正しい順序で出力する必要があるため)、ユーザーは進行状況の99%まで出力を見ることができないため、これは私にとって問題です。

MSDN のこの記事を読んで、FIFO グローバル キューが あることを知りましたThreadPoolが、各スレッドにはタスクを実行するための LIFO ローカル キューがあります。これはおそらく、この奇妙な動作を避けるために、ThreadPool自分で を使用して作成するべきではないことを意味しますか? そうですか?誰か提案はありますか?

4

1 に答える 1

0

はい、これは正しいです。PLINQ を使用してファイル内の行を処理することをお勧めします。PLINQ は順序を保持し、正確な並列度を使用できます。

于 2012-10-18T15:54:53.063 に答える