Concurrency and Coordination

October 30, 2006

Buried inside Microsoft’s Robotics Studio is the Concurrency and Coordination Runtime (CCR). This is the runtime layer for the dataflow programming model for their robotics toolkit. Basically, it’s a message-passing runtime that uses their own simplified threadpool design. I’m going to write some tests to compare it with Erlang’s performance, i.e. process creation time and message-passing throughput. Ideally, I’d like to include concurrency specifications in the comments of my C# program, then extract them and run them in a model checker. That way I can validate the concurrency aspect of my programs. I’d also like to write my programs in F#, which would provide stronger type-checking and pattern matching (very useful for message passing). I hope it works, or I’ll be forced to roll my own.

[added] Each process is really a delegate, so process creation time is equal to object creation time. .NET can probably create more objects per second than Erlang’s runtime. I did a very simple ping-pong test (two processes sending messages back and forth). It can send 800K messages per second. This is a very rough test. I’ll duplicate some Erlang benchmarks and report those.


2 Responses to “Concurrency and Coordination”

  1. Stuart Smith Says:

    You might be interested in our approach to concurrency and coordination. The primary aim of our technology is to simplify the writing of scaleable, resilient, concurrent/distributed software solutions especially in the case of irregular concurrency. It would appear to us that the majority (if not all) of the other programming tools available seem to target ‘data parallel’ applications. We believe that we are the only provider of a solution that is effective for both regular and irregular concurrency.
    We have not implemented a DSL in an ‘application related’ sense as we regard the area of concurrency as the domain we are interested in. It has been our intent to seperate the communications aspects of the solution from the algorithmic/processing aspects of the solution (similar to a co-ordination language). However, we extend the toolset to allow the developer to describe his/her solution using a graphical editor to create something similar to an electronic circuit; this will then be translated to the target language (currently C++). The developer will then be able to write the processing/algorithmic code without any knowledge of the threading/locking/synchronisation issues that writing ‘thread-aware’ code would entail.
    We have a runtime which allows the solution to run on a number of OS’es without any changes, and, to run on any hardware topology without any changes (single process on one or more CPU’s (SMP), on shared memory multiprocessors (AMP), and/or heterogeneous networks of these platform types). This ‘hardware agnostic’ approach facilitates the development of the solution on, say, a desktop PC and allows the choice of hardware to deferred until closer to time of deployment. Hope this interests you from at least from a technological point of view.

  2. projectshave Says:

    Stuart: The CLiP tool you’ve described sounds very good. Can it statically verify models for concurrency bugs? I’ll be using SPIN to check my models. On Windows, I also need to ensure that my GUI code run on a specific thread because UI controls have thread affinity. For my prototype and first version, I’m going to use C# (and F#) because it’s easier. When I eventually move some code to C++, I’ll definitely take another look at CLiP.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: