Comment Feed for Concurrency and Coordination Runtime (Going Deep on Channel 9)

Re: Concurrency and Coordination Runtime

hack2roothotmai — Fri, 04 Sep 2009 00:55:12 GMT

Hi everyone! You are welcome to try my commit to the community and play with my framework samples at http://plugins.codeplex.com

Sincerely yours,
hack2root

Re: Concurrency and Coordination Runtime

basbossink — Tue, 09 Oct 2007 07:08:19 GMT

Great stuff! Very inspiring. In the video a small demo is shown of the 'concurrent msbuild' application the team build with the ccr. I would like to know if it's possible to recieve a copy of this application or if it might be released in some shape or form in the near future.

Thanks in advance.

Greets,

Bas Bossink

Re: Concurrency and Coordination Runtime

georgioc — Thu, 20 Jul 2006 19:10:14 GMT

sumothecat wrote:
Very enjoyable video! I have a simplistic question -- I thought a "runtime" was something that loaded code and managed its execution (e.g. CLR, Java runtime). This is a type library -- what makes it a "runtime"? Thanks!

The CCR, even if its a library, actually manages all execution, replacing the CLR thread pool or any manual threading code. Underneath ofcourse it uses the OS+CLR.

The CCR manages messages on ports, task load balancing and execution, iterator task stepping, dispatcher lifetime etc. So its somewhere between a library and an execution environment. If you check out our robotics video, it might make it a little bit more clear why the CCR is a fundemental piece of our execution environment

Re: Concurrency and Coordination Runtime

georgioc — Tue, 20 Jun 2006 12:30:17 GMT

ok the bits are live. You can go to msdn.microsoft.com/robotics, and download the setup. its kind of big since it includes a few external components but once it installs, the CCR dll will be under \bin. Take a look at the service tutorials that come as part of the robotics SDK. The CCR is used as part of a service model that will give you cross machine distribution, in addition to concurrency and coordination within a machine.

July 9th you will also get a MSDN article ont he CCR with sample code using it in various scenarios.

Re: Concurrency and Coordination Runtime

georgioc — Mon, 19 Jun 2006 05:40:48 GMT

Hi, the CCR is ready for its first public release. It will be available tuesday as part of a new product CTP we will announce then. It is an independent part, so people just interested in the CCR can use it by itself. I will post the link tuesday. Also expect another channel9 video showing the ccr in action

Re: Concurrency and Coordination Runtime

SamuelLeon — Sun, 18 Jun 2006 05:11:59 GMT

I haven't heard anything about CCR in a while. Is work still being done? Is a June release still planned?

Re: Concurrency and Coordination Runtime

georgioc — Mon, 03 Apr 2006 18:08:04 GMT

yes ports are definately thread safe!

Re: Concurrency and Coordination Runtime

nunoc — Mon, 03 Apr 2006 07:51:30 GMT

Great! Those features really do simplify the implementation of our app. :)
What I meant in the the first question was if the Ports are threadsafe: for instance, can I post to them from different CCR Tasks, eventually running simultaneously, without having to worry about race conditions in the Port's object, right?

Re: Concurrency and Coordination Runtime

georgioc — Fri, 31 Mar 2006 13:43:47 GMT

Yes, ports, dispatchers etc are regular C# objects so they can be used anywhere you use and store object references.

Yes ports can be extended. You just implement the appropriate interfaces or easier, derive from Port<T>. We used to have LIFO, random insert implementations but again and again FIFO became the norm due to to starving issues related to LIFO and the distruptive attributes non-FIFO methods have on streaming or preserving sequence of events.

messages stored on ports, are by reference. We have extended some of our Arbiters (for example we have a variant of Receiver<T>) that deep clone objects before waking up the user task+ delegate associated with the port. The CCR allows you to do this type of extensies trivially and in a manner that the sender (the process that Posts) never has to know about. As i mentioned earlier we have a distributed system built on top of it

Re: Concurrency and Coordination Runtime

nunoc — Fri, 31 Mar 2006 10:31:43 GMT

Hi again!

Can the Ports, Queues and Dispatchers be used as "globals" (class variables, for instance) from within the tasks?

Is it possible to extend a Port with a different strategy (like a LIFO or a priority queue instead of a FIFO)?

How are the objects passed by the ports to the tasks? By reference or copied?

Thanks!

Re: Concurrency and Coordination Runtime

nunoc — Wed, 29 Mar 2006 05:54:37 GMT

Thanks! And I'm also looking forward to see the distribution features you mentioned!

Re: Concurrency and Coordination Runtime

georgioc — Tue, 28 Mar 2006 18:14:55 GMT

what you are doing is perfectly valid. In the recent refactoring we did, we removed operator overloads. All runtime features are still there however, including dynamically creating choice, join, etc.

The wiki has the latest API.

Re: Concurrency and Coordination Runtime

georgioc — Tue, 28 Mar 2006 18:11:53 GMT

current release is planned for this june. Just 2 months away

Re: Concurrency and Coordination Runtime

valdair — Tue, 28 Mar 2006 15:23:54 GMT

Is there a place we can now get the CCR? I'm really wanting to get my hands on this for my current project.

Re: Concurrency and Coordination Runtime

nunoc — Tue, 28 Mar 2006 08:57:10 GMT

Hi! I have been playing with the CCR and I think it takes away some of the pain of working with concurrency, which is very good!
However I'm a little confused of how should one program with the CCR :s

For instance, is it correct to send ports to ITasks and post from within them (like in the following example)?

  static void HandlerPorts(Port<int> pInts)
  {
   pInts.Post(42);
  }

  static void Main(string[] args)
  {
   using (Dispatcher dispatcher = new Dispatcher(0, "CcrDispatcher"))
   {
    DispatcherQueue queue = dispatcher.AddQueue("MainQueue");
    Port<int> pInts = new Port<int>();
    Port<Port<int>> pPorts = new Port<Port<int>>();

    Arbiter.Activate(queue, Arbiter.Receive<int>(true, pInts,
     delegate(int value){
      Console.Out.WriteLine(value);
     }
     ));

    for(int i=0; i<2; i++){
     Arbiter.Activate(queue, Arbiter.Receive<Port<int>>(false, pPorts, HandlerPorts));
     pPorts.Post(pInts);
    }
    System.Threading.Thread.Sleep(1000);
   }
  }

This seems to work as I want, printing twice the value 42. But am I messing with the CLR in any way I shouldn't?

Also, is the API defined anywhere? I've heard that there are some quite neat ways of using the CLR (operator overloading, like the | for choice).

Thanks and keep up the good work! :)
Nuno

Re: Concurrency and Coordination Runtime

georgioc — Fri, 03 Mar 2006 05:50:00 GMT

We actualy have built distributed system infrastructure on top of the CCR. The CCR itself is not ofcourse about distribution (you need other machinery for that, which sounds you have built already) but it helps you with coordinating I/O, so it was a good fit for our distributed work. With some simple adaptors over .NET system apis (like web requests, sockets, streams) we were able to have one consistent way to deal with i/o and load balance well.

So i see no reason why you cant use this in your system.

I really want to get this out there, and have people play with it. As i said, in a couple of months you can play with the CCR, plus a bunch more that has been built on top of it ;) Its currently in good shape and as i mentioned earlier Jeff Richter is working with us to simplify the object model and then write up an article on it.

g

Re: Concurrency and Coordination Runtime

valdair — Thu, 02 Mar 2006 23:08:45 GMT

I have to admit this looks amazing and is exactly what we need on my current project. I currently have a distributed server system that accesses data locally and on other machines, but I'm having difficulty adding parallelism to the system. I believe this would allow me to easily add this if I can massage the dispatcher to not only load balance across processors but across machines.

Georgio do you see this as being already built in or at least a workable implementation on my part? I already have a running system (in .net 2.0) capable of handling thousands of requests a second, and I believe I can easily shoehorn this into it. We are still months away from going live so hopefully the timing will be workable on my part to use this.