PLINQ の潜在的な落とし穴

2025-06-17

多くの場合、PLINQ では、LINQ to Objects のシーケンシャルクエリよりもパフォーマンスが大幅に向上します。ただし、クエリ実行を並列化する作業では複雑さが生じ、シーケンシャルコードでは一般的ではないか、まったく発生しないという問題が発生する可能性があります。このトピックでは、PLINQ クエリを記述するときに回避するいくつかのプラクティスを示します。

並列が常に高速であると想定しないでください

並列化により、PLINQ クエリの実行速度が LINQ to Objects と同等よりも遅くなる場合があります。基本的な経験則として、ソース要素が少なく、高速なユーザーデリゲートを持つクエリの速度が大幅に向上する可能性は低いということです。ただし、パフォーマンスには多くの要因が関係するため、PLINQ を使用するかどうかを決定する前に、実際の結果を測定することをお勧めします。詳細については、「 PLINQ の高速化について」を参照してください。

共有メモリの場所への書き込みを避ける

逐次コードでは、静的変数またはクラスフィールドから読み取ることや、これらの場所に書き込むことはよくあります。ただし、複数のスレッドからこのような変数に同時にアクセスしているときは、著しい競合状態になる場合がよくあります。ロックを使用して変数へのアクセスを同期できる場合でも、同期のコストでパフォーマンスが低下する可能性があります。そのため、PLINQ クエリの共有状態へのアクセスは、可能な限り回避 (または少なくとも制限) することをお勧めします。

過剰並列化を回避する

AsParallelメソッドを使用すると、ソースコレクションのパーティション分割とワーカースレッドの同期のオーバーヘッドコストが発生します。並列化の利点は、コンピューター上のプロセッサ数によってさらに制限されます。 1 つのプロセッサで複数の計算主体のスレッドを実行しても、高速化は実現しません。そのため、クエリを過剰に並列化しないように注意する必要があります。

次のスニペットに示すように、過剰並列化が発生する可能性がある最も一般的なシナリオは、入れ子になったクエリです。

var q = from cust in customers.AsParallel()
        from order in cust.Orders.AsParallel()
        where order.OrderDate > date
        select new { cust, order };

Dim q = From cust In customers.AsParallel()
        From order In cust.Orders.AsParallel()
        Where order.OrderDate > aDate
        Select New With {cust, order}

この場合、次の条件の 1 つ以上が適用されない限り、外部データソース (顧客) のみを並列化することをお勧めします。

内部データソース (cust.Orders) は非常に長いとされています。
各注文でコストのかかる計算を実行しているこの例で示されている操作は高価ではありません。
ターゲットシステムには、 cust.Ordersでクエリを並列化することによって生成されるスレッドの数を処理するのに十分なプロセッサがあることがわかっています。

どの場合も、最適なクエリの形式を決定する最善の方法は、テストおよび測定することです。詳細については、「方法: PLINQ クエリのパフォーマンスを測定する」を参照してください。

スレッドセーフでないメソッドの呼び出しを回避する

PLINQ クエリからスレッドセーフでないインスタンスメソッドに書き込むと、データが破損し、プログラムで検出される場合とされない場合があります。例外が発生する可能性もあります。次の例では、複数のスレッドが、クラスでサポートされていない FileStream.Write メソッドの同時呼び出しを試みます。

Dim fs As FileStream = File.OpenWrite(…)
a.AsParallel().Where(...).OrderBy(...).Select(...).ForAll(Sub(x) fs.Write(x))

FileStream fs = File.OpenWrite(...);
a.AsParallel().Where(...).OrderBy(...).Select(...).ForAll(x => fs.Write(x));

スレッドセーフメソッドへの呼び出しを制限する

.NET のほとんどの静的メソッドはスレッドセーフであり、複数のスレッドから同時に呼び出すことができます。ただし、このような場合でも、関連する同期によっては、クエリの処理速度が大幅に低下する可能性があります。

注

これは、クエリに WriteLine の呼び出しをいくつか挿入することで自分でテストできます。このメソッドは、デモンストレーションの目的でドキュメントの例で使用されますが、PLINQ クエリでは使用しないでください。

不要な順序付け操作を回避する

PLINQ は、クエリを並列で実行すると、ソースシーケンスを複数のスレッドで同時に操作できるパーティションに分割します。既定では、パーティションが処理され、結果が配信される順序は予測できません ( OrderBy などの演算子を除く)。ソースシーケンスの順序を保持するように PLINQ に指示できますが、パフォーマンスに悪影響を及ぼします。可能な限りベストプラクティスは、順序の保持に依存しないようにクエリを構成することです。詳細については、「 PLINQ での注文の保持」を参照してください。

可能な場合は ForAll を ForEach に優先する

PLINQ は複数のスレッドでクエリを実行しますが、 foreach ループ (Visual Basic では For Each ) で結果を使用する場合は、クエリ結果を 1 つのスレッドにマージし、列挙子によって順次アクセスする必要があります。場合によっては、これは避けられません。ただし、可能な限り、 ForAll メソッドを使用して、たとえば、 System.Collections.Concurrent.ConcurrentBag<T>などのスレッドセーフなコレクションに書き込むことで、各スレッドが独自の結果を出力できるようにします。

Parallel.ForEachにも同じ問題が適用されます。言い換えると、 source.AsParallel().Where().ForAll(...) は Parallel.ForEach(source.AsParallel().Where(), ...)より強く優先される必要があります。

スレッドアフィニティの問題に注意する

シングルスレッドアパートメント (STA) コンポーネント向けの COM 相互運用性、Windows フォーム、Windows Presentation Foundation (WPF) などの一部のテクノロジでは、特定のスレッド上で実行するコードを必要とするスレッドアフィニティが制限される場合があります。たとえば、Windows フォームと WPF では、コントロールへのアクセスは、そのコントロールが作成されたスレッド上でしか行うことができません。 PLINQ クエリで Windows フォームコントロールの共有状態にアクセスしようとすると、デバッガーで実行している場合は例外が発生します。 (この設定はオフにできます)。ただし、クエリが UI スレッドで使用されている場合は、そのコードが 1 つのスレッドで実行されるため、クエリ結果を列挙する foreach ループから制御にアクセスできます。

ForEach、For、ForAll のイテレーションは常に並列で実行されると想定しないでください

Parallel.For、Parallel.ForEach、またはForAll ループ内の個々の反復は、並列で実行する必要はない場合があることに注意することが重要です。そのため、イテレーションの並列実行の正確性、または特定の順序でのイテレーションの実行の正確性に依存するコードを記述しないでください。

たとえば、次のコードはデッドロックが起こる可能性があります。

Dim mre = New ManualResetEventSlim()
Enumerable.Range(0, Environment.ProcessorCount * 100).AsParallel().ForAll(Sub(j)
   If j = Environment.ProcessorCount Then
       Console.WriteLine("Set on {0} with value of {1}", Thread.CurrentThread.ManagedThreadId, j)
       mre.Set()
   Else
       Console.WriteLine("Waiting on {0} with value of {1}", Thread.CurrentThread.ManagedThreadId, j)
       mre.Wait()
   End If
End Sub) ' deadlocks

ManualResetEventSlim mre = new ManualResetEventSlim();
Enumerable.Range(0, Environment.ProcessorCount * 100).AsParallel().ForAll((j) =>
{
    if (j == Environment.ProcessorCount)
    {
        Console.WriteLine("Set on {0} with value of {1}", Thread.CurrentThread.ManagedThreadId, j);
        mre.Set();
    }
    else
    {
        Console.WriteLine("Waiting on {0} with value of {1}", Thread.CurrentThread.ManagedThreadId, j);
        mre.Wait();
    }
}); //deadlocks

この例では、1 つのイテレーションでイベントを設定し、その他のすべてのイテレーションでイベントを待機します。待機のイテレーションは、イベント設定のイテレーションが完了するまで完了できません。ただし、待機のイテレーションによって、並列ループの実行に使用されるすべてのスレッドがブロックされ、イベント設定のイテレーションがまったく実行されなくなる可能性があります。これにより、イベント設定のイテレーションが実行されず、待機のイテレーションが開始されないままの状態になるデッドロックが発生します。

具体的には、処理を適切に進めるには、並列ループの特定のイテレーションでそのループの別のイテレーションを待機するのは避ける必要があります。並列ループで、イテレーションが逆の順序で順次スケジュールされた場合、デッドロックが発生します。

こちらも参照ください

Parallel LINQ (PLINQ)