![\"concbag\"](\"https:\/\/blogs.msdn.com\/blogfiles\/pfxteam\/WindowsLiveWriter\/WhatsnewinBeta1forthecoordinationdatastr_CBB0\/concbag_2.gif\" "\\"concbag\\"")
<\/a> Figure 1.\u00a0 How threads access elements in a ConcurrentBag<T>.<\/font><\/b><\/p>\n<\/b><\/p>\n
ConcurrentLinkedList<T> and ConcurrentLinkedListNode<T> .csharpcode, .csharpcode pre{\tfont-size: small;\tcolor: black;\tfont-family: consolas, “Courier New”, courier, monospace;\tbackground-color: #ffffff;\t\/*white-space: pre;*\/}.csharpcode pre { margin: 0em; }.csharpcode .rem { color: #008000; }.csharpcode .kwrd { color: #0000ff; }.csharpcode .str { color: #006080; }.csharpcode .op { color: #0000c0; }.csharpcode .preproc { color: #cc6633; }.csharpcode .asp { background-color: #ffff00; }.csharpcode .html { color: #800000; }.csharpcode .attr { color: #ff0000; }.csharpcode .alt {\tbackground-color: #f4f4f4;\twidth: 100%;\tmargin: 0em;}.csharpcode .lnum { color: #606060; }<\/p>\n TryInsertBetween will walk the list and insert the value only when the supplied predicate returns true. It does all this atomically.\u00a0 If it fails, it returns false without changing the list.<\/p>\n Partitioner<T> and OrderablePartitioner<T> <\/span><\/p>\n For example, say I\u2019ve created a thread-safe collection that protects elements with striped-locking (where elements 0, 3, and 6 are protected by lock A, 1, 4, and 7 by lock B and 2, 5, and 8 protected by lock C).\u00a0 If we just use the standard enumerator and the pattern will look like: acquire lock A, acquire lock B, acquire lock C, acquire lock A, acquire lock B, and so on.\u00a0 This is hardly an efficient manner to partition out elements, especially if other threads are playing around with the data structure.\u00a0 It would be much more efficient if we acquired each lock just once.\u00a0 In a perfect world, if Parallel.ForEach decided that three threads wanted to enumerate this hypothetical data structure, we\u2019d want to give all of the elements under lock A to one thread, the elements of lock B to another and the elements of lock C to the last, significantly reducing the amount of time spent acquiring locks and potentially waiting for locks to be given up.\u00a0 <\/font><\/font><\/span><\/p>\n <\/p>\n \u00a0<\/p>\n <\/font><\/font><\/p>\n \u00a0<\/p>\n <\/span><\/p>\n We\u2019ll be posting more detail on partitioners soon, but suffice it to say that Partitioner<T> allows you to create custom partitioning algorithms for any data source.\u00a0 OrderablePartitioner<T> does the same, but keeps account of each element\u2019s original index so the data can be reordered when necessary. Each of these abstract classes supports both static partitioning as well as dynamic partitioning. In addition to these extension points, we\u2019re providing a few out-of-the-box partitioners, but I\u2019ll keep you in suspense \u2013 check back for more detailed posts on partitioners soon!<\/font><\/span><\/p>\n In addition to adding new types, we also decided to cut one out.<\/p>\n WriteOnce<T> There are lots of minor refactors and name changes coming in Beta 1 but there\u2019s only one major change for the coordination data structures that we should call out: LazyInit<T>.\u00a0 I won\u2019t list every name change an name space change but it\u2019s important to see how LazyInit<T> has been refactored. Originally, LazyInit<T> was a struct which gave it all the nuances that come with a value-type.\u00a0 We\u2019ve since refactored LazyInit<T> into four types: <\/p>\n In addition to the refactoring, Lazy<T> and LazyVariable<T> now have both thread-safe and<\/i> non-thread-safe initialization modes for those that need the lazy initialization functionality without the overhead of synchronization.\u00a0 <\/p>\n In the Beta 1 release, you\u2019ll find a few types for a unified cancellation model intended to be used throughout the .NET framework.\u00a0 Cancellation holds enough merit to warrant a dedicated post on it so we\u2019ll be posting one soon.\u00a0 What\u2019s exciting is that we\u2019ve added cancellation support throughout TPL, PLINQ and the coordination data structures.\u00a0 For the data structures specifically, we\u2019ve added cancellation overloads to any of our APIs that may block, including: <\/p>\n Again, there are too many minor changes to call out but just be aware that some types have moved to different namespaces and might have some APIs that were renamed.\u00a0 <\/p>\n There are two API additions worth calling out, however:<\/p>\n SpinWait.SpinUntil ConcurrentStack<T>.PushRange and ConcurrentStack<T>.PopRange Check back soon for what\u2019s new in TPL and PLINQ!<\/p>\n","protected":false},"excerpt":{"rendered":" We’re currently working on the Beta of .NET 4.0 (no dates to announce) and there are lots o\u2019 new stuff for the Parallel Extensions.\u00a0 We hope you\u2019re as excited about it as we are.\u00a0 Given that we have so much coming down the pipes, we decided to roll out posts on what\u2019s coming in digestible […]<\/p>\n","protected":false},"author":486,"featured_media":58792,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[7908],"tags":[],"class_list":["post-2263","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pfxteam"],"acf":[],"blog_post_summary":" We’re currently working on the Beta of .NET 4.0 (no dates to announce) and there are lots o\u2019 new stuff for the Parallel Extensions.\u00a0 We hope you\u2019re as excited about it as we are.\u00a0 Given that we have so much coming down the pipes, we decided to roll out posts on what\u2019s coming in digestible […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/2263","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/486"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=2263"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/2263\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=2263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=2263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=2263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
<\/b>ConcurrentLinkedList<T> is essentially a thread-safe version of LinkedList<T>.\u00a0 Of course there are some caveats, this is <\/i>parallel programming we\u2019re talking about.\u00a0 \ud83d\ude42 Just inserting a value into a linked list becomes difficult in a multi-threaded world.\u00a0 Say you want to add items to a list in sorted order.\u00a0 With single-threaded linked lists, this is a simple as walking the list and finding the position where the left node is less than the value you want to insert and the right node is greater than or equal to that value.\u00a0 In a concurrent environment, between the time you\u2019ve found the location and actually added the value, another value could have been inserted in that place or one of the neighboring nodes removed.\u00a0 Thus, ConcurrentLinkedList<T> provides methods that support these tasks with atomic operations, like the TryInsertBetween method:<\/p>\nlist.TryInsertBetween( (left, right) => ((left.Value < item) && (right.Value > item)), item);<\/pre>\n
<\/b>When TPL or PLINQ consume a data structure, they do their best to load balance the elements between threads.\u00a0 Of course, TPL and PLINQ don\u2019t have detailed knowledge about the data sources, such as each structures internals, the values of the data, and the length of the data source \u2013 all of which are factors in execution time. The APIs simply see that a type implements IEnumerable<T> or IList<T> and start processing the elements based on enumeration or indexing.\u00a0 Often times, this means that significant performance gains are overlooked.\u00a0 Partitioners allow you to achieve these gains.<\/span><\/p>\nRemoved Types<\/h3>\n
<\/b>In short, WriteOnce<T> was never really more than a simplification on top of Interlocked.CompareExchange and that doesn’t provide enough value at this point to warrant a new type in the .NET Framework. Farewell!<\/p>\nRefactors<\/h3>\n
\n
Cancellation<\/h3>\n
\n
\n
Misc. Changes<\/h3>\n
<\/b>We realized that a lot of scenarios for SpinWait went something like this\u2026 Check a condition. If false, spin.\u00a0 Check a condition, if false, spin. Check a condition.\u00a0 If false spin\u2026 We decided to make it a tad easier by allowing you to pass a Func<Boolean> to SpinWait, causing it to spin until the condition was met or a timeout occurred. <\/p>\n
<\/b>We\u2019re all about squeezing out that last drop of performance and where we can, we do.\u00a0 Take ConcurrentStack<T> for example, which works on a single CompareAndSwap (CAS) operation if there is no contention.\u00a0 Many scenarios involve pushing or popping a series of items on or off the stack which typically results in looping through a collection, calling Push() on each item.\u00a0 This of course, results in N CAS operations and potentially a lot more if the stack is being contended on by multiple threads.\u00a0 Since we only need to do one CAS operation to update ConcurrentStack<T> anyway, we might as well build up a stack segment first and then push the whole segment onto the stack with a single CAS – reducing the number of potential retry CAS operations.\u00a0 Enter PushRange and PopRange, which do exactly that.<\/p>\n