{"id":55961,"date":"2009-11-05T19:44:00","date_gmt":"2009-11-05T19:44:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/pfxteam\/2009\/11\/05\/whats-new-for-the-coordination-data-structures-in-beta-2\/"},"modified":"2009-11-05T19:44:00","modified_gmt":"2009-11-05T19:44:00","slug":"whats-new-for-the-coordination-data-structures-in-beta-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/whats-new-for-the-coordination-data-structures-in-beta-2\/","title":{"rendered":"What\u2019s new for the coordination data structures in Beta 2?"},"content":{"rendered":"

Rejoice!  Visual Studio 2010 Beta 2 is upon us and it includes lots of great changes for the Parallel Extensions.  TPL guru Danny Shih has already covered what\u2019s new in TPL<\/A> and PLINQ aficionado Ed Essey has covered the best way to use LINQ<\/A> (specifically between Beta 1 and Beta 2) but your favorite set of thread-safe collections and synchronization primitives are in on the action too.  <\/P>\n

So what\u2019s changed?  Overall, we\u2019ve been fixing bugs, of course, but we\u2019ve also spent a lot of time fine-tuning these types to get the best performance possible.  That said, performance varies greatly from architecture to architecture and from scenario to scenario, so make sure you stick on your detective hat, fire up the Concurrency Visualizer<\/A> and go sleuthing around your app\u2019s performance profile to ensure that you\u2019re using the right types in the right way.  We\u2019re always happy to see perf results and field perf-related questions on our forum<\/A>.<\/P>\n

I\u2019m not going to talk about specific bugs or perf improvements here but let\u2019s jump into functionality that\u2019s been added or changed:<\/P>\n

Barrier
<\/STRONG>In Beta 1, Barrier used to track phase numbers using a 32-bit integer.  While most scenarios for Barrier couldn\u2019t conceive of exhausting a range of 4+ billion numbers, for long running services, it\u2019s not infeasible.  That\u2019s why we\u2019ve decided to change Barrier to track phases using a 64-bit integer (so check for any code that called AddParticipant{s} or CurrentPhaseNumber).  We encourage you to take comfort in the fact that your tasks and threads can joyously join together in cyclic fashion for an eternity*.  <\/P>\n

Also, in previous releases, if you decided to give Barrier a Post Phase Action to execute when all threads completed a phase, any exceptions thrown from that action would be thrown unwrapped and only on the thread that actually ended up executing the action.  We\u2019ve since realized that that\u2019s a little silly.  If your Post Phase Action faulted, more than likely, your algorithm is corrupt but only one thread would know about it.  In Beta 2, all<\/EM> of your threads participating in a Barrier are now privy to these kinds of failures: any exceptions thrown from your action are wrapped in a BarrierPostPhaseException and thrown on all the threads that participated in that phase. <\/P>\n

*Not really an eternity. A really really long time though.  <\/FONT><\/P>\n

BlockingCollection<T>
<\/STRONG>Good ol\u2019 blocking collection. It\u2019s giving producer threads and consumer threads everywhere a common ground upon which to communicate and brimming with thread-safety at every API.  What\u2019s that you say?  In Beta 1 BlockingCollection<T>.Add() and BlockingCollection<T>.CompleteAdding() were not thread-safe with respect to each other?  Using them concurrently might\u2019ve corrupted the data structure so in Beta 1 you couldn\u2019t do something like a nice parallel graph-traversal?<\/P>

var targetNode = \u2026;\nvar bc = new<\/SPAN> BlockingCollection<Node>(startingNodes);
\/\/ since we expect GetConsumingEnumerable to block, limit parallelism to the number of
\/\/ procs, avoiding too much thread injection<\/FONT>
var parOpts = new ParallelOptions() { MaxDegreeOfParallelism = Enivronment.ProcessorCount };\nParallel.ForEach(bc.GetConsumingEnumerable(), parOpts, (node,loop) =>\n{\n    if<\/SPAN> (node == targetNode)\n    {\n        Console.WriteLine(\u201chooray!\u201d);\n        bc.CompleteAdding();\n        loop.Stop();\n    }\n    else<\/SPAN>\n    {\n        foreach<\/SPAN>(var neighbor in<\/SPAN> node.Neighbors) bc.Add(neighbor);\n    }\n});<\/PRE>\n
Well worry no longer.  Our team of concurrency-geniuses has crammed even more<\/EM> thread-safety into BlockingCollection<T> for your graph-traversing pleasure by making these two methods thread-safe. (Note that Add() will now throw an exception if called after CompleteAdding() has been called so with Beta 2, you\u2019ll need to put a catch block around the call to Add in this example.)<\/P>\n
ConcurrentDictionary<TKey,TValue><\/STRONG> 
Since Beta 1 has released, we\u2019ve gotten a lot of feedback, both internal and external, about ConcurrentDictionary<TKey,TValue>.  CD is slightly more special than the other concurrent collections added in .NET 4: unlike the other collections, it provides direct access to all of it\u2019s elements.  This, of course, supports a whole different set of scenarios.  While ConcurrentStack<T>, ConcurrentQueue<T>, and ConcurrentBag<T> are really about processing arbitrary elements, ConcurrentDictionary<TKey,TValue> is about processing elements associated with known keys.  With the former, threads will only race on access to the end elements of the collection.  With the latter, access to every element may result in a race.  That said, in Beta 1, it was very difficult to do any multi-step operations with the elements in a ConcurrentDictionary<TKey,TValue>.  Suppose you just wanted to create a simple thread-safe cache.  You were forced to check if the value existed and add it if it did not. Of course, in the time between checking for the item and adding it, an element with the same key could have been added, forcing you to check for such a condition and trying again.  <\/P>\n
Enter two new atomic multi-step operations* on CD: GetOrAdd and AddOrUpdate.<\/P>\n
GetOrAdd allows you to specify a key as well as a value (or delegate to produce the value). The method will atomically check for the existence of a given key and, if the key already exists, return the existing value.  If the key does not exist, this method will add the new value you\u2019ve specified (with or without the delegate).  For example:<\/P>
private<\/SPAN> ConcurrentDictionary<string<\/SPAN>, Data> _cache = \n    new<\/SPAN> ConcurrentDictionary<string<\/SPAN>,Data>();<\/p>\n
\/\/ on multiple threads<\/SPAN>\npublic<\/SPAN> Data ProcessRequest(string<\/SPAN> input)\n{\n    return<\/SPAN> _cache.GetOrAdd(input, (key) =>\n    {\n         …;\n         return<\/SPAN> …;\n    }    \n}<\/PRE><\/p>\n
.csharpcode, .csharpcode pre\n{\n\tfont-size: small;\n\tcolor: black;\n\tfont-family: consolas, “Courier New”, courier, monospace;\n\tbackground-color: #ffffff;\n\t\/*white-space: pre;*\/\n}\n.csharpcode pre { margin: 0em; }\n.csharpcode .rem { color: #008000; }\n.csharpcode .kwrd { color: #0000ff; }\n.csharpcode .str { color: #006080; }\n.csharpcode .op { color: #0000c0; }\n.csharpcode .preproc { color: #cc6633; }\n.csharpcode .asp { background-color: #ffff00; }\n.csharpcode .html { color: #800000; }\n.csharpcode .attr { color: #ff0000; }\n.csharpcode .alt \n{\n\tbackground-color: #f4f4f4;\n\twidth: 100%;\n\tmargin: 0em;\n}\n.csharpcode .lnum { color: #606060; }<\/p>\n
AddOrUpdate enables you to either add a new element at a given key or update an existing one if that key already exists, great for scenarios that need thread-safe lookup-tables like counting the number of occurrences of a given string in parallel:<\/P>
private<\/SPAN> ConcurrentDictionary<string<\/SPAN>,int<\/SPAN>> _counts = \n    new<\/SPAN> ConcurrentDictionary<string<\/SPAN>,int<\/SPAN>>();<\/p>\n
\/\/ on multiple threads<\/SPAN>\npublic<\/SPAN> int<\/SPAN> CountRequest(string<\/SPAN> input)\n{\n    return<\/SPAN> _counts.AddOrUpdate(input, 1, (key,old) => old + 1);\n}<\/PRE><\/p>\n
.csharpcode, .csharpcode pre\n{\n\tfont-size: small;\n\tcolor: black;\n\tfont-family: consolas, “Courier New”, courier, monospace;\n\tbackground-color: #ffffff;\n\t\/*white-space: pre;*\/\n}\n.csharpcode pre { margin: 0em; }\n.csharpcode .rem { color: #008000; }\n.csharpcode .kwrd { color: #0000ff; }\n.csharpcode .str { color: #006080; }\n.csharpcode .op { color: #0000c0; }\n.csharpcode .preproc { color: #cc6633; }\n.csharpcode .asp { background-color: #ffff00; }\n.csharpcode .html { color: #800000; }\n.csharpcode .attr { color: #ff0000; }\n.csharpcode .alt \n{\n\tbackground-color: #f4f4f4;\n\twidth: 100%;\n\tmargin: 0em;\n}\n.csharpcode .lnum { color: #606060; }<\/p>\n
With AddOrUpdate, you specify the key that you\u2019re interested in, the value to add if the key is not present (or a delegate to create that value), and, finally, a delegate that will generate the new value in the case that the key is already present.  This delegate passes along the key and existing value key so your delegate can use it to determine the new value.  <\/P>\n
Nifty!<\/P>\n
*Atomic with regards to other mutating methods on the collection (e.g. TryAdd\/TryUpdate\/TryRemove\/etc.), excluding the execution of the user-provided delegate.  This means that if multiple threads race to call GetOrAdd all of their delegates may be called and some delegates may be called multiple times. Users are expected to rollback any unwanted side-effects.<\/P>\n
ConcurrentLinkedList<T> and ConcurrentLinkedListNode<T> 
<\/STRONG>In each and every software professional\u2019s career there comes a point where he or she might have to swallow their pride and let a creation that they love go.  For some reason or another, their fancy invention just ultimately, doesn\u2019t provide enough value to justify its existence.  Now I know we went and got you all excited about ConcurrentLinkedList<T> in Beta 1 but we had to let it go (we did warn you though!).  Unfortunately, with the time we had available we just couldn\u2019t get it to be usable and<\/EM> perform well.  There seem to be many thread-safe linked list implementations that are very scalable but usually that scalability is based on some assumption or odd caveat in the design that severely degrades the practicality of the type.  It hurts us deeply to take CLL<T> out but its performance just wasn\u2019t good enough to ship it.  No need to send any flowers.<\/P>\n
Lazy<T>, LazyInitializer, and ThreadLocal<T> 
<\/STRONG>Oh boy has Lazy<T> been fun!  In Beta 1, we told you that we renamed LazyInit<T> to Lazy<T>, added a new struct-based version called LazyVariable<T> and moved the thread-local mode over to its own type (ThreadLocal<T>).  Well, in the interest of making these primitives as usable as possible, we\u2019ve gone and done it again!  Here\u2019s a breakdown of the lazy-initialization primitives in Beta 2:<\/P>\n