Do LINQ Operators block at all?

I'm looking at the output from VS2010 Concurrency Profiler and I notice that I'm getting some thread contentions around some of the LINQ operators. Here is开发者_JAVA百科 the statement causing the contention:

m_dictionary.PermutableSubunits.Select(subunit => subunit.Number).ToArray()

Do the LINQ operators block? Should I be more careful about using them in a Task that is running as part of a Parallel.ForEach?

I assume that you are asking about LINQ to Objects, and so the Select call in your code corresponds to Enumerable.Select(..).

LINQ to Objects operators themselves do not explicitly block the executing thread. However, they do allocate memory: for example, the ToArray operator will allocate larger and larger arrays in order to buffer up the results.

And, memory allocations can result in thread blocking. When you allocate memory, the CLR or the OS may need to acquire some lock in order to locate a chunk of free memory. Even more importantly, the CLR may decide to run garbage collection (GC) any time you allocate memory, and that can result in significant thread blocking.

If server GC is a good fit for your application, you can try turning it on and see if the throughput improves. Also, you can often write non-LINQ code that performs fewer memory allocations than a LINQ to Objects query. In your particular example, I believe that LINQ to Objects will start producing the results into a small array, allocating a larger array any time the results don't fit. Your custom implementation may be able to allocate the array of the right size right at the beginning, avoiding a bunch of unnecessary allocations.

It shouldn't block, but if you're using Linq-to-SQL it may take exceptionally long if your query is taking a long time to execute... in general, any time you're doing something with multithreading you should be "more careful" or as they say: "thread carefully!"

However, if you're having contention issues, then you should really analyze what you're actually doing. Linq is not thread safe, so if you're performing a read/write operation on a entity that has the potential to change from another thread, then you should synchronize properly.