RE: [aus-dotnet] Has anyone used the CCR?

[ILT]

OK, I’ve found that I can answer my own question by poking around a bit more.

The MSDN Forum [Microsoft Robotics - Concurrency and Coordination Runtime (CCR) ] is fertile ground, including reference to a paper [PDF] on the use of CCR for high performance computing on multicore systems.

A part of the abstract reads –

A common underlying runtime that supports multiple programming paradigms appears to be one important part of future parallel computing environments integrating cluster and multicore parallelism. Here we examine CCR or the Concurrency and Coordination Run time from Microsoft as a multi-paradigm run time supporting three key parallel models: full MPI collective messaging, asynchronous threading and coarse grain functional parallelism or workflow.  It is an attractive multi-paradigm candidate as it was designed to support general dynamic message patterns with high performance and already has a distributed, REST oriented runtime known as DSS built on top of it. We present results on message latency and bandwidth for two processor multicore systems based on AMD and Intel architectures with a total of four and eight cores. Generating up to a million messages per second on a single PC, we find on the AMD based PC, latencies from 4µs in basic asynchronous threading and point to point mode to 14 µs for a full MPI_SENDRECV exchange with all threads (one per core) sending and receiving 2 messages at a traditional MPI loosely synchronous rendezvous. Workflow latencies are measured as less than 40 µs with all results coming from the CCR and DSS freely available as part of the Microsoft Robotics Studio distribution.

 

Also, there is a small number of helpful blog posts.

 

Further information on licensing and cost (3^rd hand, via Peter Blomberg):

---

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...

---

IL Thomas
GeoSciSoft  - Perth, Australia

---

From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of ILT
Sent: Wednesday, June 13, 2007 3:27 PM
To: dotnet@xxxxxxxxxxx
Subject: [aus-dotnet] Has anyone used the CCR?

 

Following on from the Joel Pobar Perth session on concurrency, I came across CCR via a message post at CodeProject.

The CCR - Concurrency and Coordination Runtime for asynchronous processing (see here, for a description by Peter Blomberg) – may offer in the CCR.Core assembly (154Kb) some welcome help with threading and concurrency, beyond using the excellent BackgroundWorker control and a lot of brain-power for the more elaborate scenarios.

Unfortunately to get the 154K assembly it is necessary to download 50Mb of the Microsoft Robotics Studio May 2007 CTP.

Has anyone seen code / blog / more thorough descriptions? Or – better – used the assembly and compared its ease of use and applicability with roll-your-own management of threads and concurrency using eg the thread pool?

Here’s a description from Bromberg’s Unblog for those that are interested.

---

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.

[ MORE ]

---

IL Thomas
GeoSciSoft  - Perth, Australia