Concurrency and Coordination Runtime

Sometimes I stumble over some new technologies on the internet and I say to myself “this is just too good to be true”. Recently I came across some nice tutorials and videos about the concurrency and coordination runtime of Microsoft. My first thought was that this is one of that “too good to be true” technologies. But then I did a closer look and decided that this technology is worth mentioning on planetgeek.

The Microsoft Concurrency and Coordination Runtime (short CCR) is part of the Microsoft CCR and Decentralized Software Services (DSS) toolkit which is available both for .NET 3.5 SP1 and .NET 3.5 Compact Framework. The mind blowing core of the toolkit is the CCR which has originally evolved from the Microsoft Robotics Platform and Research. Due increase demands of customers Microsoft decided to put the core technology into the toolkit and provide it for the software community.

CCRs main focus is to address the problems that developers need to deal with when creating loosely-coupled concurrent applications. CCR introduced a completely new way of dealing with concurrent code. CCR eliminates the complexities of manual threading, locks and semaphores. CCR also simplifies the complexity of dealing with exceptions that occur in asynchronously executed code. CCR provides a highly sophisticated and fair scheduler which automatically does load-balancing across multiple cores.

What is really cool with CCR is that actually using CCR can be reduced in the usage of the following three components: Ports, Arbiters and Dispatchers.

The Port is a generic class which offers various operations to send and retrieve type safe information from asynchronous operations. So the interaction with asynchronous operation is always done by accessing port objects, no matter if the asynchronous operation actually returned the desired result or throwed an exception.

The Arbiter is actually the coordinator of CCR. The arbiter acts as a static factory which is responsible for creating coordination and interaction objects which allow to manage the flow of the concurrent/asynchronous operations.

The Dispatcher is the actual thread pooling mechanism behind CCR. The dispatcher is responsible for dispatching the various asynchronous tasks which are defined via the port objects and the arbiter.

I really recommend to have a look at this video:

http://channel9.msdn.com/pdc2008/TL55/

checkout the CCR tag on channel9

http://channel9.msdn.com/tags/CCR/

also have a look at this site:

Concurrent Affairs

So don’t you think this is cool or is it for you a “too good to be true” technology? Decide for yourself and let me know what you think!