Reed Copsey, Jr. has been writing a great series of articles on parallelism with the .NET Framework 4…

I am still having a hard time grasping this LocalState example and how it is different than original locking issue. In my mind I have the following:

a) There is some kind of WorkItemQueue filled with the doubles in the collection.
b) There is a pool of Threads where the # of threads is “generally” based on the # of processing elements (i.e. cores)
c) The TPL will unleash all the threads in the pool at once
d) Rathe than issuing a single WorkItem per thread, the TPL “partitions” the WorkItemQueue such that each thread gets a chunk of WorkItems.

I am to understand that the Action(TLocal) is the delegate that is called at the conclusion of the thread/task processing each WorkItem in its chunk…head scratching.

Also, in early comment you mentioned the overhead if a Dictionary was used. However, this may minimized with the use of the the ConcurrentDictionary….rendering a MapReduce-like solution. Regardless, a lock is necessary somewhere I suppose. Ah…. never-mind….I cheated and looked ahead….I see the nice PLINQ example in Part 6 . Nice!

I should have written “to host the aggregation delegate *and maintain a per-thread accumulator variable*, which would be significantly more cumbersome.”

Do I have this right?

Behind the scenes, Parallel.ForEach is creating a ThreadLocal to store the local state, using the ThreadLocal(Func) constructor. So the TPL decides how many threads it will use and executes your local state initialization delegate once for each thread (on the first iteration handled by that thread).

In a world without ThreadLocal, .NET would need a factory method to create an object instance to host the aggregation delegate, which would be significantly more cumbersome.