Expert to Expert: Meijer and Chrysanthakopoulos - Concurrency, Coordination and the CCR

The Discussion

• 

  Epic! Best video on C9 so far. And that says a lot.

• 

  All I can say is Wow.

• 

  Does anyone else think that if we could somehow plug Erik and George into the power grid we could solve the energy crisis Joking aside, another brilliant video. It would be a poorer programming, intellectual and creative world without Channel 9 that's for damn sure.

• 

  I'm happy to hear you enjoyed this! George and Erik make for great edutainment. There are so many nuggets of wisdom in this piece that you'll be able to mine successfully for quite some time. 
  
  I promise not to point my camera into a window again (sorry about that, but I did not want to stop the conversation to set up George on the other side of the room - just as George made the comment in this discussion thatconcurrency happens, so too do conversations and I hate to mess with the real time alchemy of my Channel 9 interviews...) and limit my dumb questions to just one or two!
  
  C

• 

  
  
  Thank you.
  C

• 

  Thanks Charles. Great watch. And you were as good as your word about asking George about CCR uptake. My interpretation was that, being outside of the Developer Division they haven't necessarily had access to the marketing muscle available within it. Nevertheless, kudos to you and Channel 9 for following the CCR over the past 5 years - to paraphrase Erik, there are popular things and there are important things...
  

• 

  I love the CCR, I've said this various times before .. I really need to start playing with it in order to fully appreciate where I could use it.

• 

  Thanks for the feedback!
  
  I'd like to start up a discussion (on this thread) regarding two very interesting points brought up in this conversation:
  
  1) Concurrency happens
  

  • Coordination should be your focus. Concurrency is a side effect of well-coordinated systems
  • Understanding and handling failure is paramount to acheiving reliable (and reasonable) coordination

  2) Mash-Ups as a good conceptual model for programming coordinating systems (well, Mash-Ups that are able to communicate across constituent boundaries...)
  
  I think these are very important concepts that deserve some more discussion and thought.
  
  Coordinatingly,
  C

• 

  way cool cant watch right now but i will so do it later
  george is awsome and he has a way to describe things that make all the alternatives seem stupid still, ive found the ccr somewhat difficult to approach (but then again, what is my puny brain against those of erik and george ) also, i feel like making orchestrations in MSRDS is somewhat detached from the rest of the development experince :/ i wonder of vs10 will bring the ccr more into mainstream development i hope so atleast (maybe this is talked about in the video)
  
  i'll comment more on the points that you bring charles after ive watched the video but i generally think that concurency and cordination always happens and have happend for a long time, but we as mainstream programmers have only recently started paying attention to it  its an interesting topic indeed

• 

  Great video!
  
  However - I've been fascinated by the CCR ever since it turned up as a topic on CHannel 9.  Now, it seems to be oretty complete, and I thought this may be the time to try to change one of our server applications to use the CCR rather than using Threadpools etc.
  
  Well - what's with the licensing?  I don't want any robotics junk installed on my development-machine, still, I want to try out the CCR, so I found this page: http://www.microsoft.com/ccrdss/#GetIt
  
  Am I supposed to spend $300 to TEST OUT the CCR in a clean environment?  Come on...
  
  And volume license...?  We want to use this as a mechanism in a single server-app (on ONE server) for starters, there is no DSS involved.
  
  Am I missing something?
  
  
  
  

• 

  Hi, you can try out the CCR (and DSS) for free just by downloading  Microsoft Robotics Express SDK (available from www.microsoft.com/robotics).
  
  Volume licensing will be available as well in the next month or so.

• 

  Great talk guys! Really hits the core of many things here.

  1) Concurrency happens.
  Having used the CCR, I understand what G. is saying here. Once your system is factored with ccr-"agents" this way and the message passing boundaries are defined with Ports, then your Agent "hides" and handles its own state - so it is more naturally composable in many respects. This is similar to what Eric has been saying with Functions. Functions can safely run in parallel because they are self contained and don't modify external state - they get an input and return an output. A CCR service does not have this strong of a contract. The programmer can make it unsafe, but if you follow some patterns, it makes it far more approachable to do things correctly.  I think what he is saying is you *have to have coordination and correctness *first. Once you have that, concurrency can then happen correctly, because the model is correct. Then you can dump 1000 cores at it, and it does not matter, because your correct and scaling can just happen.  That said, the model needs to raise another level of abstraction to make it Correct-by-Contruction because it is still too easy to do it wrong or just not "see" a race or a fifo logic error. But I think projects like Maestro are addressing this area with compiler/language to support the Model.

  2) Mash-ups.
  This is a good analogy for web devs. Other folks may find SOA or just Services a better analogy. I think Hue(?) from a WCF video said "Every object should be a service". He was right, the model has to change. I don't think we need every object a service, but we need to be able to draw a circle around N objects and define the service boundary. It makes it very clean because it does not matter if service is remote, in-proc, or out-of-proc. The model is the same in all cases.

  3) Is it difficult?
  IMO, I don't think it is. It is different, but don't think it any harder then hooking up events. You have to think about Joins and stuff, but you will end up doing that anyway using more difficult patterns (locks, Reset Events, etc). IMO, the Port abstraction makes it easier to reason about your services and makes the boundaries explicit and loose. I think the issue people may be having is not thinking about using CCR model as a Whole application model. They are thinking only about making a specific thing concurrent. When you do this, you end up trying to "wrap"/abstract the Port/Handler model instead of exposing it to other parts of your program. This means you can spend time doing the wrong thing - turning your async Port abstraction back into a sync method call - which is counter to the service idea.  You need to embrase the Port abstraction in your Whole program.  Make services and make it composable. You can then version easily, drop/restart services dynamically, Pipelining becomes easy, can also refactor services as needed on onto different machines. 
  
  4) Take it to the extreme.
  Lets say in a new world, everything is surfaced as a ccr Port. Files are "Ports", serial Ports, usb Ports, keyboard Ports, Scanner Ports, video Port, the UI is a Port, etc.
  Everything has a Port abstraction and you have *ONE model to program against everything and coordinate everything. That is a powerful model. And it is not sci-fi, you could do this today yourself with your own Port wrappers. Things like the Windows POS library should be Port based as well.
  
  --William

• 

  great stuff the ccr is really awsome, but im still having some trouble putting it all into practice :/ that is really frustrating because it makes so much sense, i feel like im just missing the final pice of the puzzle
  
  it would be really awsome to see some more code showing these simple (for you guys at least) coodination scenarios with the ccr. like a simple wpf app that talks to a bunch of services, how would that be done with the ccr.. i think i remeber something like that from a ccr video from waaaay back but it'd be nice to have a refresh and also a few more ones like that
  
  i think that would really help avg joe programmers like myself get into the ccr
  
  great stuff as always charles

• 

  Show us a simple example of how to benefit from the CCR in a simple winforms or ASP app.

• 

  I'd second staceyw's comments and add a few of my own.
  
  Once I understood the model, I did stop thinking about concurrency per-se, in the sense that I stopped worrying about threads and locks. I still have to worry about state, because its my responsibility to *not* schedule simultaneous writes to the same memory, but this scheduling is *much* easier to reason about than before. I suppose in this sense, I am thinking about coordination and not concurrency. Although I get rather nice core utilisation for 'free'.
  
  Programmers unfamiliar with the CCR are often scared off by the perceived implications of a message-passing model. But the CCR's lightweight model is still very efficient, and whilst the straightline traditional model might be a few percent quicker, but I'll take the CCR most times because in the long-run I personally get a better overall result, not just in terms of performance, but also failure handling, robustness, scalability and clarity. And even if you just used it to introduce some asynchronous I/O into your app, you'd be amazed the difference that alone can make.
  
  Interestingly, where you do still have to think about threads, locking, blocking etc, is around the boundaries where you are communicating with some non-compatible api/threading model, say COM, or WinForms/WPF. I don't know when (if ever) the user interface will move away from a model of thread-affinity, but on the client-side I think there's always a bit of a jarring switch between CCR and UI. It's doable but not entirely satisfying.
  
  On the point of failure, as soon as you move to an asynchronous message-passing model, you pretty much can't assume that your message will even be delivered, (b) it will be delivered correctly or within time constraints, (c) the object will handle it correcly, (d) any response gets delivered (e) any response get's delivered within time constraints. You can ignore any one or more of these conditions, but you're system will live-lock pretty quickly if you're only ever waiting indefinitely for the successful response. The CCR model makes you consider these possible failures, but through its arbiters and causalities gives you the mechanisms to deal with them. And this leaves your code in much better shape when you really physically distribute because you're prepared for the much more likely scenario of timeout and network failure.
  
  The final point I'd make is kind of related to mash-ups. While the asynchronous message-passing actor/agent model is a good approach for composing distributed systems from a 'temporal' perspective, from a functional perspective, surely mash-ups work because the operations you can perform against the various data sources (basically GET and POST) are relatively simple, uniform in their behaviour and well understood. Some are even actually RESTful . The DSS model, that sits above CCR takes a similar view of distributed state manipulation. It would be good to get a Going Deep on the DSS to the same extent that we've seen on the CCR itself, because just using CCR to make your SOAP/WSDL clients/servers more efficient, isn't going to make them more composable.
  
  Nick.
  
  
  

• 

  Very insigtful, you guys! I like the idea of a GD on DSS.
  
  Keep the feedback coming!
  C

• 

  I would like to hear more about integration between concurrency paradigms, formally and practically - in software stacks. To quote Niklas Gustafsson 

  
  

  "The developer division concurrency runtime, on the other hand, is designed to serve as low-level infrastructure for a variety of programming models surfaced in libraries and languages."

  
  

  "Therefore, we are looking into how we can integrate the CCR functionality on top of the concurrency runtime once we have shipped the latter; it's important to us that it work well with other libraries that may also be used in an application, such as OpenMP, MPI, PLINQ, etc."

  
  

  PS - https://www.microsoft.com/ccrdss/

• 

  Josh's Rule states that the mean enthusiasm for a technology is inversely proportionate to the ratio of deployments the technology over the sum of the competing technology deployments.  I'm glad C9 is getting interviews with folks that are doing coordination without solely using the framework primitives, otherwise it could get a little apathetic around here.  I'll have to start a CCR project and post comments about my experience.  Great Show.

• 

  Example of a race I was talking about.  Even though the model may be correct, a subtle race exists and could be hard to find.  In this case it was obvious:
  http://www.microsoft.com/winme/0703/29490/Visual_Programming_Language_(VPL)_1/Local/index.html">http://www.microsoft.com/winme/0703/29490/Visual_Programming_Language_(VPL)_1/Local/index.html
  Andreas may have not even noticed it.  In the TextToSpeech VPL sample (last example), it started at "2" and number "1" came between 9 and 10.  This is a Port race as the port really needs to process fifo in this case.  Can someone please explain how to fix that using  VPL in the activity?  Thanks much. 

• 

  Awesome! Good stuff
  

• 

  
  Awesome interview!...
  
  I've been working on a framework based on the same coordination principles. It allows me to run computer vision, 3d rendering, physics and sound, in separate cores and not having to worry about state sharing...
  
  You can see a couple of resulting videos here:
  http://www.youtube.com/watch?v=SJLTskfbY8s
  http://www.youtube.com/watch?v=Sw5N32xGRaw
  
  
  
  

• 

  esoteric, is there something you'd specifically like to hear about wrt to the Concurrency Runtime? I'm assuming you've seen the other posts here talking about it.

• 

  Simply brilliant, one of the most interesting and inspiring videos so far...
  

• 

  Thank you! Much more like this to come.
  C

• 

  Will the Robotic Developer Studio  2008 by available with a MSDN subscription? We can download versions 1.0 and 1.5 now.

• 

  This is the best video I've seen on here in quite a while.  I would love to see more videos on the CCR & DSS that take the theories and mindsets presented in this video and apply them to real programs.  Something like "Here is how your code might have looked before CCR, here are the steps we took to make it work with the CCR, and here is the final result.".  Programs with long-running blocking operations are definitely a good candidate, but also perhaps showing how trickier coordination issues like loading a mesh of interdependent resources concurrently (loading a webpage and all its resources is a good example) could be simplified with something like the CCR.

• 

  Awesome talk. Thanks.
  
  More please on applicaiton models. Please!
  And mp4  impossible to watch over 3G network. Would be nice to lower bitrate a bit or to make mobile versions of talks.
  
  Thanks.

• 

  We will create low bit rate MP4s. It's on our radar!
  C

• 

  "Understanding and handling failure is paramount"
  
  While I think this is a very important part of engineering well coordinated system, and pretty much any system, in general, the long term play is to remove the need for managing exceptions in code, in the same vein as the declarative programming push for LINQ or other features focused on raising the level of abstraction. As George stated in the video, robots have a very apparent failure result, they just fall off a cliff or fail to complete thier task. It's the "Live" lock scenarios that have become so numerous and pervasive as a result of poor software composability. Microsoft is definitely on the right track in addresing this in basically all areas of development right now by trying to raise the level of abstraction above the ground, where an updated concurrency model (or any update) can be applied without disturbing the "Eloi". On the flip side, "Morlocks" want to move between both worlds if necessary (Anders talks about this alot), but the default experience should be (arguably) one of a declaritive nature when it comes to writing programs. The entrepreneur is not concerned about a stack trace, just how to actualize the idea. I actually fall on the other side. I want to see all the dirty little details.
  
  I really enjoyed this video, mainly because of George's passion for this subject. I was amazed to hear that writing games or doing robots was a preferred instructional path because of the way it teaches you fundamentals of concurrency and how to think in these terms. It makes sense, and it made me open my mind a bit more. I should go pick a MS robotics kit and some Legos, all kidding aside.