2

私は次のようにロギングメソッドを実装しました：

 ThreadPool.QueueUserWorkItem((state) => {
    lock (appendLock) {
       using (StreamWriter log = File.AppendText(_logFile)) {
          log.WriteLine(message);
       }
    }
 }, null);

1：lock必要ですか？ロギングをスレッド化したかったのですが、ロックがすでに設定されていることがわかりました。そのため、そのコードを変更するのではなく、単にワーカーデリゲートにラップしました。

2：ロックが必要であると仮定します：これは、ロックを含むデリゲートをキューに入れるための正しい実装ですか？複数のスレッドがログ書き込みを要求している可能性はかなり高いです。デリゲートをワーカースレッドにエンキューすることにより、ファイルI/O実行の長さがアプリケーション自体に影響を与えないようにする必要があります。

3：複数のワーカーがキューに入れられていると仮定しlogWriteDelegateます：デリゲートは、受信した順序で呼び出されますか？つまり、現在＃32を提供しています...現在＃33を提供しています

4

1 に答える 1

2

1：はい、ロックする必要があります。特にプールを使用しているため、複数のスレッドからアクセスできます。

2：まあ、それは動作します。ただし、ファイルはロックされたままになり、読みにくくなります。この問題に多くの効果をもたらした既存のロギングフレームワークがあります。それらを使用する価値があるかもしれません。

3：いいえ; ロックとプールを使用すると、最終ファイルで厳密な順序付けを期待しない2つの別々の理由になります。実際、プールが原因で、単一のスレッドのメッセージが順不同で表示される可能性があります。順序付けが必要な場合は、（同期された）キューに書き込み、データを（同期された）キューからプルしてログファイルに書き込む専用のワーカーを用意する必要があります。繰り返しますが、既存のロギングフレームワークがこれを解決します。

于 2012-07-28T15:23:44.903 に答える