Known Issues in Parallel Extensions to .NET 4.0 Beta1
We’re excited to have the Beta in your hands. (See .NET 4 Beta 1 is now available, with parallelism!) As you use it, please keep in mind the following known issues which we plan to address after Beta1.
1. Do not take a dependency on the System.Collections.Concurrent.ConcurrentLinkedList<T> class, because it is being removed.
Workaround: Use the System.Collections.Concurrent.ConcurrentQueue<T> class instead, or alternatively use the System.Collections.Generic.LinkedList<T> class with standard .NET synchronization mechanisms.
2. Do not take a dependency on the System.LazyVariable<T> class, because it is being removed.
Workaround: Use the System.Lazy<T> class instead.
3. The System.Collections.Concurrent.ConcurrentQueue<T>.TryRemove method may hang in Beta 1 if the ConcurrentQueue<T> was constructed from an existing collection, and the size of the pre-existing collection was non-zero and a multiple of 32.
Workaround: Initialize the ConcurrentQueue<T> with the default constructor and add the collection’s elements into the queue individually using the Enqueue method.
4. There is a potential race condition internal to the System.Threading.Tasks.TaskCompletionSource<TResult> class in Beta 1. For a given TaskCompletionSource<TResult> instance, if the TrySetResult method is called at the same time that the associated Task’s Result property is read, the value read from Result may be incorrect.
Workaround: There is no known workaround. However, this bug manifests with Result returning default(TResult) instead of the correct value (the correct value may of course be default(TResult)). So, if Result returns something other than default(TResult), you can trust that value to be accurate.
5. In PLINQ in Beta 1, AsOrdered followed by a GroupBy only preserves the ordering of the groupings, not of the elements within the groupings.
Workaround: Call OrderBy on each of the groupings to sort them separately, or use LINQ-to-Objects instead of PLINQ.
6. In Beta 1, Tasks parented to other tasks may not be garbage collected until the parent task is available for collection. This may result in out-of-memory conditions if a Task launches a very large number of attached child Tasks but itself does not become available for collection. As Parallel LINQ uses Tasks internally, this may also occur for Tasks that are used to repeatedly run parallel queries.
Workaround: Large collections of child tasks may be wrapped in detached tasks to avoid implicit parenting behavior.
7. The task replication mechanism employed by System.Threading.Parallel in Beta 1 may react negatively to the ThreadPool’s work item starvation heuristic. This can result in unbounded thread growth over time for very long running loops.
Workaround: Use a ParallelOptions instance that has MaxDegreeOfParallelism set to an appropriate maximum.
8. In Beta 1, System.Threading.Parallel.For‘s current partitioning scheme may cause it to perform poorly in scenarios that have large numbers of iterations and very small loop bodies.
Workaround: See “How to: Speed Up Small Loop Bodies” http://msdn.microsoft.com/en-us/library/dd560853(VS.100).aspx
As always, please use the Parallel Extensions to .NET forum to let us know if we missed anything.
Happy coding!
Light
Dark
0 comments