CCR Introduction

Microsoft Robotics
Concurrency and Coordination Runtime (CCR) is a managed code library, a Dynamically Linked Library (DLL), accessible from any language targeting the .NET Common Language Runtime (CLR).
The CCR addresses the need of service-oriented applications to manage asynchronous operations, deal with concurrency, exploit parallel hardware and deal with partial failure. It enables the user to design applications so that the software modules or components can be loosely coupled; meaning they can be developed independently and make minimal assumptions about their runtime environment and other components. This approach changes how the user can think of programs from the start of the design process and deals with concurrency, failure and isolation in a consistent way.

Problem Areas

Asynchrony - When communicating between loosely coupled software components, like programs running across the network, or User Interface (UI) code communicating with the user input and the file I/O subsystem, asynchronous operations enable the code to scale better, be more responsive, and deal with failure across multiple operations. Asynchronous programming however, considerably reduces the readability of user code, since logic is often split between callbacks and the code that originates the operation. In addition, it is an almost impossible task to correctly handle failure across multiple outstanding operations.
Concurrency - Code that needs to better utilize multiple execution resources, must be split into independent logical segments, that can run in parallel, and communicate when necessary to produce results from the combined execution. Often, that logical segment is captured by the thread OS primitive, that is nothing more than a long lived iteration. Because of thread performance implications on thread startup, the thread stays active for long periods of time. This forces a particular pattern. Code is structured as long sequences that use blocking or synchronous calls, and only deals with one thing at a time. Further, threads assume that the primary communication between them is shared memory, forcing the programmer to use very explicit, error-prone methods to synchronize access to that shared memory.
Coordination and Failure Handling - Coordinating between components is where most of the complexity in large software programs lies. A mismatch of interaction patterns, such as calling methods on objects versus using OS signaling primitives versus using queues plus signaling, leads to unreadable code, where the runtime behavior changes drastically between coordination approaches. More importantly, the error handling approaches are ill-defined and again vary drastically.
Application Model

CCR is appropriate for an application model that separates components into pieces that can interact only through messages. Components in this model need means to coordinate between messages, deal with complex failure scenarios, and effectively deal with asynchronous programming. This application model is also very similar to how heterogeneous hardware is integrated and how network applications are built. Most software programs have the same needs, from traditional client PC programs to server applications, to applets running in the Web browser. The software needs to coordinate user input, storage input/output and UI presentation. Although disguised in layers of mostly synchronous application code interfaces, asynchrony is inevitable since the devices operate at different speeds, have large differences in resources available, and we in general know how to use queues to isolate them.

The following sections introduce the CCR programming model and its implementation that addresses the above areas in an efficient, robust and extensible way.





© 2010 Microsoft Corporation. All Rights Reserved.