System.Lazy <T>は異なるスレッドセーフモードと

Question

.NET 4.0のSystem.Lazy<T>クラスは、私のように要約します列挙LazyThreadSafetyMode、を介して3スレッドセーフモードを提供しています：

• LazyThreadSafetyMode.None - スレッドセーフではありません。
• LazyThreadSafetyMode.ExecutionAndPublication-1つの並行スレッドだけが、基礎となる値の作成を試みます。作成に成功すると、待機中のスレッドはすべて同じ値を受け取ります。未処理の例外が作成中に発生した場合は、待機中の各スレッドで再スローされ、キャッシュされ、後続の各値のアクセスに再スローされます。
• LazyThreadSafetyMode.PublicationOnlyから複数の同時実行スレッドは、基礎となる価値を創造しようとしますが、成功するために最初は、すべてのスレッドに渡された値を決定します。作成中に未処理の例外が発生した場合、そのオブジェクトはキャッシュされません。同時に&の基本値にアクセスしようとすると、作成が再試行されます。&が成功する可能性があります。

私はすなわち、わずかに異なるスレッドの安全規則を次のレイジー初期化された値を持っているしたいと思います：

つだけの同時スレッドが根底にある価値を創造しようとします。作成に成功すると、待機中のスレッドはすべて同じ値を受け取ります。未処理の例外が作成中に発生すると、待機中の各スレッドで再スローされますが、キャッシュされず、その後の値にアクセスしようとすると、作成が再試行されます。&が成功する可能性があります。

のでLazyThreadSafetyMode.ExecutionAndPublicationとキーdifferinceは、作成時に「最初に行くには、」失敗した場合、それは後で再試行することができるということです。

これらのセマンティクスを提供する既存の（.NET 4.0）クラスはありますか、それとも独自にロールバックする必要がありますか？私が自分自身をロールバックする場合、明示的なロック/同期を避けるために、既存のLazy <T>を実装内で再利用するスマートな方法がありますか？

---

N.B.ユースケースの場合、「作成」は高価で潜在的に断続的なエラーが発生する可能性があると想像してください。リモートサーバーから大量のデータを取得します。私はおそらくすべてが失敗するか、すべて成功するので、データを取得する複数の同時の試みをしたくないです。しかし、失敗した場合は、後で再試行することができます。

Answer 1

競合状態I pointed out ...のないバージョンのDarin's updated answerで私の試行を警告しましたが、これは最終的には完全に競合状態がないことは完全にはわかりません。

private static int waiters = 0; 
private static volatile Lazy<object> lazy = new Lazy<object>(GetValueFromSomewhere); 
public static object Value 
{ 
    get 
    { 
     Lazy<object> currLazy = lazy; 
     if (currLazy.IsValueCreated) 
      return currLazy.Value; 

     Interlocked.Increment(ref waiters); 

     try 
     { 
      return lazy.Value; 

      // just leave "waiters" at whatever it is... no harm in it. 
     } 
     catch 
     { 
      if (Interlocked.Decrement(ref waiters) == 0) 
       lazy = new Lazy<object>(GetValueFromSomewhere); 
      throw; 
     } 
    } 
} 

アップデート：私は、私はこれを掲示した後、競合状態を発見したと思いました。この動作は実際には受け入れられるはずです。ある種のスレッドが例外をスローする場合は、おそらくまれです。Lazy<T>他のスレッドが既に成功したファストLazy<T>から戻ってきた後に（将来の要求はすべて成功します）。

• waiters = 0
• T1：ちょうどInterlocked.Decrement（= 1 waiters）
• t2の前まで走行に来る：に来て、ちょうどInterlocked.Increment（= 1 waiters）
前までに実行され
• T1：そのInterlocked.Decrementと（= 0 waiters）を上書きする準備
• T2を行いますちょうどInterlocked.Decrement（前まで走ります= 1）
• T1：lazy T3
• 新しいもの（lazy1それを呼び出す）（= 1 waiters）
とを上書き：T2
• ）= 2 waiters（lazy1上及びブロック付属：んそのInterlocked.Decrement（ = 1 waiters）
• T3：lazy1から値を取得し、返す（waitersは現在無関係である）
• T2：その例外を再スロー

「このスレッドは、別のスレッドが成功した結果、このスレッドが例外をスローした」よりも悪いことが起こる一連のイベントが発生しません。

Update2：保護された上書きがすべての読者によって直ちに確認されるように、lazyをvolatileと宣言しました。一部の人々（自分自身を含む）はvolatileを参照し、すぐに「よく、おそらく間違って使用されている」と思っています。上記の例のイベントシーケンスでは、lazyをlazy1に変更した直後に、lazy1の代わりにt3がの代わりにlazy.Valueの直前に配置されていた場合、t3はまだt1がlazyに変更された瞬間を読み取ることができました。 volatileはそのことから保護し、次の試行をすぐに開始できるようにします。

なぜ私は頭の後ろに「ローロック・コンカレント・プログラミングは難しいのですが、C＃lockステートメントを使用しています」ということを思い出しました。私が元の答えを書いていた時間全体。

Update3と：ちょうどvolatileが必要になり、実際の状況を指摘アップデート2でいくつかのテキストを変更する - 私はもともと持っていたとして、ここで使用さInterlocked操作は、明らかに、今日ではなく、ハーフフェンスの重要なCPUアーキテクチャにフルフェンスを実施しています単純に並べ替えられているので、私が元々考えていたよりもはるかに狭い部分を保護します。volatileこのような