CCR Programming - Jeffrey Richter and George Chrysanthakopoulos

Posted By: Charles | Jul 24th, 2006 @ 11:37 AM

Do you remember our introduction to the Concurrency and Coordination Runtime (CCR) with George Chrysanthakopoulos? What about our discussion with the team that implemented a robotics framework on top of it (Microsoft Robotics Studio)? Well, now we dive into the CCR API itself and learn how to use it.

If you're a developer ustilizing Microsoft platform technologies, you've probably heard of Wintellect's Jeffrey Richter. He's worked on everything from Windows to the CLR.

CCR creator George Chrysanthakopoulos commisioned Jeffrey to help make the CCR API both more approachable as well as more consitent with BCL's syntactic conventions.

Here, George Chrysanthakopoulos, Charles and Jeffrey Richter dive into demos of the CCR API as well as discuss the What How and Why of it.

At the end of the interview, you'll see an excellent real world example of how to use the CCR... (Not going to give it away. You need to watch the whole video Smiley

)

Please check out Jeffrey's latest installment of Concurrent Affairs to learn more about the new, improved CCR API and get a hold of sample code to play with. Also, see George's Microsoft Robotics Wiki for great information.

Tags: CCR, Software Composability

Rating:

Views (102,310)

Comments (95)

Downloads

Cyonix

Great video, and Charles you need to take more film next time Tongue Out

It's great having George on c9.

I haven't played with the CCR yet, but why hasn't the CCR been released on its own?

Releasing it with the robotics pack would put people off using it in general applications.

Charles

For this interview, I do wish I had brought an extra tape, but then we would have had the first two-hour interview on Channel 9!

It was great to have the people who thought up and developed the CCR (primarily George) and created the new BCL-compliant API (Jeffrey - George) explaining to us how to use the API. One of the great things about Channel 9 in my opinion is that we learn about technologies from the folks who think them up and make them...

And, we'll have more George on C9 in the future...

C

staceyw

Nice. I Always look forward to George and more CCR. I am still trying to wrap my head around how this can help with the big async need - Async Sockets! Sounds like we still need s.BeginReceive() and handle locking on shared state object parameters (i.e. bytes received) and kick off another read if we did not read enouph bytes so we can build the whole packet to parse it. Then start again for the next client request, etc. Using example like WebRequest or reading a whole file is kinda cheating because it does all that stuff for you behind the covers. How might async sockets work with the CCR in a general code flow?

What I would really like to see at some point is a way to Read the int length (i.e. 4 byte prepended length), then kick off another read to read len bytes async and don't notify me again until len bytes read or an exception. Then my delegate only needs to deal with whole packets and I can parse, process, write reply, and post another read.

BTW, the thing with the WaitForEnter() is common to what we have had to do with threaded console apps already. So not new to the CCR, but I got your point. Thanks guys and great work!!
--
wjs

Andrew Davey

Do all the nice operator overloads still exist in the CCR?
Whilst having a library that is consistent with the BCL is very important, the operator overloads really let you concentrate on only your code. Reducing code noise is an important goal IMHO. Since C# has no syntactic macro capabilities, operator overloads are the only way to abstract away the boiler plate code. (Being a purely additive feature means no has to use them if they like typing lots.)

If I get time I will look at making some syntactic macros for Boo or Nemerle, to make coding against the CCR look awesome Smiley

Also, make the CCR available as a separate download - this will certainly increase uptake by the community. (Dare I say make the project shared-source? Seeing the code would hopefully make it easier for people to write their own extensions.)

Keep up the great work!

georgioc

staceyw wrote:

Nice. I Always look forward to George and more CCR. I am still trying to wrap my head around how this can help with the big async need - Async Sockets! Sounds like we still need s.BeginReceive() and handle locking on shared state object parameters (i.e. bytes received) and kick off another read if we did not read enouph bytes so we can build the whole packet to parse it. Then start again for the next client request, etc. Using example like WebRequest or reading a whole file is kinda cheating because it does all that stuff for you behind the covers. How might async sockets work with the CCR in a general code flow?

What I would really like to see at some point is a way to Read the int length (i.e. 4 byte prepended length), then kick off another read to read len bytes async and don't notify me again until len bytes read or an exception. Then my delegate only needs to deal with whole packets and I can parse, process, write reply, and post another read.

BTW, the thing with the WaitForEnter() is common to what we have had to do with threaded console apps already. So not new to the CCR, but I got your point. Thanks guys and great work!!
--
wjs

Hi Stacey, did you take chance to play with the asynchronous web and file i/o examples Jeff has in the MSDN article? Its exactly what you want to do... As for atomically updating state, you can use our interleave pattern to protect concurrent access to state, without using locks. Just essentially annotate some piece of code as exclusive, attach that method to a port, and then issue messages when you want to do atomic updates.

The robotics service tutorials talk about this as well

georgioc

Andrew Davey wrote:

Do all the nice operator overloads still exist in the CCR?
Whilst having a library that is consistent with the BCL is very important, the operator overloads really let you concentrate on only your code. Reducing code noise is an important goal IMHO. Since C# has no syntactic macro capabilities, operator overloads are the only way to abstract away the boiler plate code. (Being a purely additive feature means no has to use them if they like typing lots.)

If I get time I will look at making some syntactic macros for Boo or Nemerle, to make coding against the CCR look awesome

Also, make the CCR available as a separate download - this will certainly increase uptake by the community. (Dare I say make the project shared-source? Seeing the code would hopefully make it easier for people to write their own extensions.)

Keep up the great work!

Hi Andrew, we are a small team, and releasing the CCR standalone, while it has been requested multiple times, is something we cant support at this time. Hopefully this will happen at some point. Until then, using the MSDN article jeff wrote, our robotics tutorials and the wiki, people get a stable runtime/library, decent user guide style documentation and the ability to try out the bits.

Releasing the source is also something we can work towards ( i think its a good idea) but i cant make any commitments at this point.

TommyCarlier

This has been one of the coolest videos on C9. I like the style, the walking through the code, asking questions, very technical content. Of course, the subject is very exciting. I've built some classes myself to simplify asynchronous programming, but it's very primitive, compared to CCR. I agree with the previous comments: bring more tape next time (2 hours of this stuff would be awesome), try to release CCR separately from the robotics pack (maybe shared-source on CodePlex?), keep the operator overloads as alternatives.

Judah

I would concur with the other posters, you guys should release this as a seperate product from the Robotics download. Just put it up as a download by itself; it doesn't need its own MSDN developer center or anything so elaborate. Smiley

Another thing I'd like to request is XML documentation on the code. I really rely on this sort of thing while coding for quick information on parameters, methods, etc. It would be a really nice thing to have.

I'm really excited about this library. My jaw dropped a little seeing the build times decrease by nearly the number of processors in the system. So many of us developers have at least hyper-threaded processors, if not physical dual core machines. The real application seems obvious there.

I am also really excited about the lockless way of sharing state by using that particular arbiter task...I think Interleave was the name. That sounds really sweet -- do you know how much we devs toil over using locks just to get the shared state right? Man, if I could move some of my code to use these interleaves rather than locks between methods, holy cow I could save so much time and probably improve performance as well. Cool

George, this library looks great and the demos really help out. I wondering if there are any demos that use Windows Forms? As you know, UI code combined with concurrency gets hairy since we can touch the UI only from a single thread. Is this something the CCR can still work with? I see a WinForms adapter bundled inside the Robotics IDE...maybe you could elaborate a little?

georgioc

Judah wrote:

I would concur with the other posters, you guys should release this as a seperate product from the Robotics download. Just put it up as a download by itself; it doesn't need its own MSDN developer center or anything so elaborate.

Another thing I'd like to request is XML documentation on the code. I really rely on this sort of thing while coding for quick information on parameters, methods, etc. It would be a really nice thing to have.

I'm really excited about this library. My jaw dropped a little seeing the build times decrease by nearly the number of processors in the system. So many of us developers have at least hyper-threaded processors, if not physical dual core machines. The real application seems obvious there.

I am also really excited about the lockless way of sharing state by using that particular arbiter task...I think Interleave was the name. That sounds really sweet -- do you know how much we devs toil over using locks just to get the shared state right? Man, if I could move some of my code to use these interleaves rather than locks between methods, holy cow I could save so much time and probably improve performance as well.

George, this library looks great and the demos really help out. I wondering if there are any demos that use Windows Forms? As you know, UI code combined with concurrency gets hairy since we can touch the UI only from a single thread. Is this something the CCR can still work with? I see a WinForms adapter bundled inside the Robotics IDE...maybe you could elaborate a little?

Regarding interleave: Yes its sweat. But what is even nicer is that you can just decorate a method with an attribute saying Exclusive or Concurrent, and we take care of the rest. This is in the context of our service runtime, DSS. In robotics, service tutorial 1 introduces this. Our service tutorials are robotics independent, we have layerd the system so CCR knows nothing about distribution (DSS) or robotics. And DSS knows nothing about robotics services but uses the CCR.

Regarding XML documentation: We hear you, at some point this willbe available. Until then i have documented all APIs with comments that should be available when you hover over the API in the VS editor

Regarding forms: We indeed have alittle wrapper, we call it the winforms service that is part of the ccr library. You basically post messages to it to launch a form, invoke handlers in the context of the UI thread etc. The robotics CTP contains services that use winforms + CCR so i would recommend you use one of them as an example.