CCR - Concurrency and Coordination Runtime for asynchronous processing

The Microsoft Robotics Studio (http://msdn.microsoft.com/robotics/), which was recently released, has a unique set of assemblies called Concurrency and Coordination Runtime (CCR). The CCR.Core assembly is only 154KB. Unfortunately, the only way you can get it (currently) is to download and install the entire April 2007 CTP:

(http://www.microsoft.com/downloads/details.aspx?FamilyId=71D96DE4-E3D9-496E-B48E-B35697C88FF1&displaylang=en) -- at 54.3 MB.

The central feature of the CCR is that it makes programming asynchronous behavior much simpler than the typical challenge of writing threaded code.

When an application's thread performs synchronous I/O requests, the application is giving up control of the thread's processing to the I/O device (a hard drive, a network, etc.). The application's responsiveness then becomes unpredictable. When threads are suspended waiting for I/O requests to complete, the application tends to create more threads in an attempt to accomplish more work. The problem is that creating, scheduling, and destroying a thread requires time and memory and can actually hurt performance rather than improve it.

The CCR offers a number of classes that provide the developer with a simple object model that you can use to express complex coordination patterns for dealing with completed I/O operations. CCR offers its own high-performance thread pool you can use to execute tasks in response to completed I/O. The thread pool offers great scalability, and when you couple the CCR with some of the new C# language features (such as anonymous methods and iterators), you have gotten an easy way to write more responsive and scalable applications.

With the CLR's thread pool, if 1,000 items are queued, there is no way for a new item to be processed until all of the first 1,000 items have been extracted from the thread pool's queue. With the CCR you can use one DispatcherQueue object for most work items and use another DispatcherQueue object for high-priority work items. The Dispatcher's threads dequeue entries from all the DispatcherQueue objects associated with it in a round-robin fashion, making your total processing much more efficient and scalable.

The Dispatcher class creates a Dispatcher object that creates and manages a set of threads. In effect, it is a thread pool. Like the CLR's thread pool, these threads call methods (via delegates) in order to execute tasks. Unlike the CLR's thread pool, there is no special thread that runs periodically checking the workload and trying to predict whether threads should be dynamically added or removed from the thread pool.

After you've created a Dispatcher, you'll construct a DispatcherQueue object. This maintains a queue of delegates that identify methods ready to execute. The Dispatcher's threads wait for entries to appear in the DispatcherQueue. As entries appear, Dispatcher threads wake up and execute the methods.

A generic Port object represents a queue of items, all of type T. Port is a way to queue an input argument to a callback method, which is analogous to the state object argument that you pass to ThreadPool's QueueUserWorkItem method.

The Arbiter class is what you use to tap into CCR coordination features. Arbiter is a static class that defines methods that are factories for creating other objects. When you call one of Arbiter's static factory methods, the method constructs an arbiter that has fields that refer to one or more ReceiverTask objects that are also constructed. There is a whole list of types of Arbiters that can be used. You can find more information about the various types of arbiters at the Channel 9 CCR wiki.

Jeffrey Richter has an excellent article that illustrates most of what you need to know to use the CCR (http://msdn.microsoft.com/msdnmag/issues/06/09/concurrentaffairs/default.aspx). There is also a forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1424&SiteID=1 .

I would package the CCR.Core.dll assembly with Richter's sample code demo from the article and make it freely downloadable so if, like me, you aren't really interested in the rest of the 54MB download, you would be able to get the CCR alone -- but I'm afraid it might be violating the EULA or some similar sinful act.

Up until now, I had never seen anything that approached a solution to these common async threading issues other than Ami Bar's SmartThreadPool project, which stands on its own as a very useful and scalable piece of code.

CCR: Highly Recommended for developers who need more flexibility and scale when writing coordinated asynchronous processing! And also, a thank you to Jon Skeet whose C# language newsgroup post reminded me that I had seen Richter's article but never took the next step, until now.

N.B. I've left a suggestion post on the forum that they break out the CCR assemblies and make them available separately. If you agree, adding a "Me too" probably wouldn't hurt the effort.

-- And here is the answer:

"we have heard this feedback many times indeed. While we do definately see alot of interest in the CCR from non robotics users, currently our team can only afford the non-trivial release management process MSFT requires, for one product/SDK. Other than the size of the download however, which i do agree is alot for a 200k lib, the CCR can be used in any application you want, with no burden or requirements on anything else in MSRS (it was and will continue to be developed as a seperate, independent component).

Another thing to note ofcourse, given its current packaging, is that the CCR is not free for commercial use. Its cost per deployment is about
2$ (our commercial license gives you 200 runtimes for 399$ for a single dev license)"

S0: the bottom line as I interpret this is that if I want to use CCR for any kind of commercial application, I have to purchase the minimum dev license for $399.00. Umm, OooKay...