Understanding PLINQ in .NET

In this article, we are going to explore PLINQ, which is the parallel implementation of LINQ. We are going to focus on when, and how to efficiently use it. 

If you need a refresher on LINQ, you can read LINQ Basic Concepts in C# article as well.

Let’s start!

Support Code Maze on Patreon to get rid of ads and get the best discounts on our products!

What is Parallel LINQ (PLINQ)?

We can safely say that PLINQ is an extension of LINQ, developed to improve our queries’ performance. With LINQ, we execute our queries in a sequential mode. This means that we process the elements in the source set one after the other. While this is typically not a performance issue, it may become one when the processing involves many CPU-bound operations. PLINQ comes to the rescue and allows us to parallelize the work on the available processors in our system. 

Why doesn’t LINQ parallelize the query execution natively?

Parallel programming is a double-edged sword. If we use it incorrectly, we could do more harm than good. For this reason, choosing whether to parallelize the execution of a query is our responsibility. If we choose to enable PLINQ, we must be aware that doesn’t come for free.

For the work to be parallelized, the source set has to be split into partitions. A partitioning algorithm assigns each data partition to a thread. When all the elements in the source set have been processed, results may be merged. Data partitioning and merging the results considerably impact the overall execution time. 

Moreover, the parallel execution of a query is safe only under the assumption of delegates’ independency. PLINQ cannot replace LINQ when the delegate reads and modifies an external variable, for example. In this case, to use PLINQ, we need to make our code thread-safe. With LINQ, this is unnecessary because we have the guarantee that each element is processed sequentially.

Let’s see how to use it!

A Simple Example of PLINQ in Action

Let’s imagine we work in a company that sells computers. We have just built a bunch of new models that we want to put on the market. Let’s create a new Computer class that represents them:

public class Computer
{
    public int GbRam { get; init; }
    public int GbSecondaryMemory { get; init; }
    public int MIPS { get; set; }
}

Before a computer leaves the company, we need to perform a certain number of tests on it. Each test process returns the number of successful tests, but could take a lot of time:

public int Test(int testCount)
{
    if (testCount > 0)
        Thread.Sleep(testCount);
    return new Random().Next() % (testCount + 1);
}

With 50 computers and 20 tests for each one, this LINQ query takes at least 1 second:

computers.Sum(comp => comp.Test(20));

With PLINQ, we can execute it in much less time, by parallelizing the delegate of the Sum() method and the sum itself:

computers.AsParallel().Sum(comp => comp.Test(20));

To enable PLINQ, we just need to call the AsParallel() method on an IEnumerable. This object is converted to a ParallelEnumerable object, which will parallelize the sum execution. We can also observe that PLINQ APIs are fully compatible with those of LINQ. This also means that a parallel query grants deferred execution, just like a normal LINQ query.

We can even set the maximum number of concurrently executing threads used by the query. If we wanted to process the same query with only 2 threads:

computers.AsParallel().WithDegreeOfParallelism(2)
    .Sum(comp => comp.Test(20));

Adjusting the degree of parallelism is useful in 2 situations. We could want to reduce the number of spawn threads to avoid keeping all the cores busy on a single query. But we can also decide to prioritize the execution of our query by incrementing the degree of parallelism.

Nonetheless, using twice the number of threads doesn’t usually mean halving the execution time. The overhead caused by data partitioning and thread synchronization is higher and higher as the degree of parallelism increases.

Before diving deeper into the subject, we need to understand when PLINQ is better than LINQ.

How Do We Choose Between PLINQ and LINQ?

Choosing between PLINQ and LINQ is not always easy.

The first thing we should ask ourselves is: does that query need to be sped up? Premature or unnecessary optimization could cause our application to require more resources than necessary. We should keep in mind that using PLINQ means stealing some resources that can be devoted to other processes.

When to Avoid Using PLINQ

Let’s see an example where PLINQ is not suitable.

We have 50 new computers, but they are very similar to some models that we are already selling. In this case, the test phase is almost useless, which is why the testCount parameter is 0:

computers.AsParallel().Sum(comp => comp.Test(0))

The overhead generated by parallelization is greater than the processing time of each element. By removing the AsParallel() call, the execution time decreases. In general, if we can quickly execute the delegate and we don’t have too many elements, then we don’t need PLINQ.

The next step is to analyze the query to find the parts that are delightfully parallel. A query, or a part of it, is delightfully parallel when it lends itself easily to scheduling on multiple threads. A delegate that is completely independent of the outer scope is delightfully parallel. Our job is to maximize the delightfully parallel parts and minimize those that bring some synchronization overhead. After some performance tests, we should be able to tell whether PLINQ is the right choice.

It might be obvious to say, but we should consider the system specifics too. If we know in advance the load and the number of cores in the production environment, our tests should take into account those limits as well. 

There are some situations where the use of PLINQ requires special care.

Don’t Parallelize Nested Loops

When we use nested loops, parallelizing both the outer and inner loops is typically inappropriate. Let’s see it with an example. We have 100 computer categories, and each computer should be tested according to its category rules:

Parallel.For(1, 100, i =>
{
    (
        from comp in computers.AsParallel().Where(c => c.GetPrice() > i)
        select comp.Test(0)
    ).ToList();
});

This is a simplified example, but the problem is in the AsParallel() call. The outer loop will probably use all of the available cores in the system. For this reason, the query, which represents the inner loop, should run sequentially. When possible, rewriting those loops as one, and then parallelizing it, is the best option we have. Otherwise, the loop to parallelize is the outer one.

Locks Decrease the Speed-up Gain

Another case of harming parallelization is when each element accesses an object protected by an exclusive lock. In our example, this can happen if we want to register each computer in the company network. The registration server processes one request at a time, so we are going to emulate it with:

public class Computer
{
    private static readonly object networkObj = new object();
    public IPAddress IPAddress { get; set; } = null!;
    // ...
    public string RegisterToNetwork()
    {
        lock (networkObj)
        {
            IPAddress = new IPAddress(new Random().Next());
            return IPAddress.ToString();
        }
    }
}

If we wanted to find all the received IP addresses, this query would be inefficient:

from comp in computers.AsParallel()
select Computer.RegisterToNetwork()

Again, this parallelized version is inefficient because the involved threads cannot access the RegisterToNetwork() method independently. A sequential query would perform better because we don’t have the overhead caused by the synchronization on the exclusive lock. In a more realistic scenario, the lock groups only the strictly necessary statements, not the entire method body. For this reason, we should make some tests to determine the possible speed-up gain of a parallel query.

Parallelize Only CPU-Bound Operations

It is very important to distinguish between CPU-bound and I/O-bound operations. For the next query, we want to ping the registered computers to find out if they are reachable. Let’s create a dummy Ping() method:

public async Task<int> Ping()
{
    await Task.Delay(30);
    return 0;
}

from comp in computers
    .AsParallel()
    .WithMergeOptions(ParallelMergeOptions.NotBuffered)
select comp.Test(10)

var query = from comp in computers
    .AsParallel()
    .WithMergeOptions(ParallelMergeOptions.FullyBuffered)
select comp.Test(1);
// build report

from comp in computers
    .AsParallel()
    .WithMergeOptions(ParallelMergeOptions.AutoBuffered)
select comp.Test(1);

var query = computers.AsParallel().Select(comp =>
{
    var key = Tuple.Create(comp.GbRam, comp.GbSecondaryMemory, comp.MIPS);
    return cache.GetOrAdd(key, k => comp.GetPrice());
});

from comp in computers.AsParallel().AsOrdered()
select comp.GetPrice();

How to Cancel Queries or Handle the Exceptions

Until now, we have assumed that our queries always terminate successfully. This is an ideal scenario because we might have to cancel them or handle the thrown exceptions. 

As for canceling queries, PLINQ perfectly integrates with the cancellation pattern. We have written an article about Cancellation Tokens so you might want to read it if you need to learn how to use them in detail. With PLINQ, we can specify the cancellation token with the WithCancellation() method.

In our company, the testing phase cannot last for more than 3 hours. After 3 hours we can stop the query using a cancellation token:

var TIME_LIMIT = 1000 * 60 * 60 * 3; // 3 hours
CancellationTokenSource cts = new CancellationTokenSource();

var query = from comp in computers.AsParallel().WithCancellation(cts.Token)
            select comp.Test(100);

Assert.ThrowsException<OperationCanceledException>(() => 
{
    var task = Task.Delay(TIME_LIMIT).ContinueWith(t => cts.Cancel());
    query.ToList();
});

We have initially created a CancellationTokenSource object that we are going to use to trigger the canceling action. Before running the query, we start a new task asynchronously, which represents the timeout for the query. After it completes, we cancel the parallel query by calling the Cancel() method on the token source. We have written an article about Tasks vs Threads where we explain the ContinueWith() method of the Task class.

When a query is canceled, the thrown exception type is OperationCanceledException. Let’s see what happens when we throw an exception in a parallel query.

How to Handle Exceptions in Parallel Queries

In a sequential query, only one exception can be thrown because we process one element at a time. In a parallel query, several threads could throw an exception at the same time. We don’t want to lose any of those exceptions, so how do we get them?

Let’s find this out with an example! In the computer company, we have a specific test phase for low-end computers. If we find some computers more expensive than 200$ in the source set, we must throw an ArgumentOutOfRangeException exception:

var query = computers.AsParallel().Select(comp =>
{
    var price = comp.GetPrice();
    if (price > 200)
        throw new ArgumentOutOfRangeException($"Price ({price}) should be lower than 200");

    return comp.Test(1);
});

Here is how we can handle them:

try
{
    query.ToList();
}
catch (AggregateException exc) 
{
    exc.Handle(ex => ex is ArgumentOutOfRangeException);
}

With the Handle() method, we return a boolean that specifies whether we have handled the exception. If the boolean value is false, then the exception is re-thrown. When we throw an exception during the query execution, all the other threads stop working as soon as possible. Then PLINQ gathers all the exceptions the threads have thrown in the meantime if any. The returned AggregateException contains all the thrown exceptions.

So far, we have seen 2 ways to run a parallel query: using the foreach construct, or the ToList() method. They are not the only ones.

var query = from comp in computers.AsParallel()
            select (comp, comp.Test(0));

query.ForAll(elem => elem.Item1.PutOnTheMarket());

Conclusions

Liked it? Take a second to support Code Maze on Patreon and get the ad free reading experience!