satnam

Another thing to note about the CCR is that it is just a library for .NET so its functionality is available to other .NET langauges. We've even written CCR programs in radicially different langauges like F# (http://research.microsoft.com/projects/ilx/fsharp.aspx) which a functional language in the style of ML. Personally, in the long run I think we need  to have langauge level support for concurrency (e.g. what we have seen with rendezvous in Ada and recent work on Sigularity http://research.microsoft.com/os/singularity/). Then we can perform static analyses to better optimize our programs and to check them for bugs. However, in the short term the CCR provides a pragmatic way to support certain kinds on concurrency programming in existing .NET languages.

Developing dynamic analyses for message passing programs is of course important (e.g. run-time debugging). However, I feel that for message passing programs that is not going to be enough. We will also need the help of more powerful static analyses to help catch problems like deadlocks. There is some interesting work involving contracts and behavioral types which looks like a promising approach. For exampe: http://www.research.microsoft.com/behave/index.htm

Our paper starts with an introduction to join patterns in the Comega langauge and we then go on to relate that to our system. You can get the paper off my website: http://research.microsoft.com/~satnams

The joins in Comega are declarations which makes them rather static. The joins in CCR are statements and they can be dynamically constructed which makes them more flexible.

If you're interested in the CCR then you might also like to look into work on software transactional memories (STMs) which are also a very promising approach for control oriented concurrency. We've written a draft paper about how to use a transactional style of programming for concurrency and you can get the paper from http://research.microsoft.com/~simonpj/