RE: [aus-dotnet] Has anyone used the CCR?

[Jonathan Parker]

I think as Steve said, writing multi-threaded apps to utilise multi-core machines is not only a HPC issue.

Is something like CCR a specifically HPC framework or do you think it could be usefully applied more widely?

 

From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of ILT
Sent: Wednesday, 13 June 2007 9:35 PM
To: dotnet@xxxxxxxxxxx
Subject: RE: [aus-dotnet] Has anyone used the CCR?

 

Not based on my opinions or assessments of CCR, but YES – you are missing something.

The blog opinions (and some that are regarded as very well informed) say to the contrary, that WPF is the inadequate or poorly-credentialled component.

There is obviously some way to go until Microsoft believes that it has a set of definitive answers about concurrency (even though Microsoft's CEO Steve Ballmer reckons it’s almost there: “Microsoft's HPC Offering Ready for Wall Street, Ballmer Says”).

What is more interesting than the usual platforms and implementation models for HPC is that Microsoft is looking for its implementation by average-Joe programmers (like me), rather than ivory tower academics or biotechnology startups with $Unlimited.

IL Thomas
GeoSciSoft  - Perth, Australia

---

From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of Jonathan Parker
Sent: Wednesday, June 13, 2007 6:49 PM
To: dotnet@xxxxxxxxxxx
Subject: RE: [aus-dotnet] Has anyone used the CCR?

 

>>The central feature of the CCR is that it makes programming asynchronous behavior much simpler than the typical challenge of writing threaded code.

 

Concurrency is definitely an interesting topic which is becoming more and more relevant with dual-core, quad-core, ??-core CPUs.

WCF allows you do make asynchronous, concurrent (a new thread for each call to a service) calls to as service.

You can even throttle calls with a simple setting of maxConcurrentCalls in the app.config.

When this limit is reached calls will be automatically queued untill some of the currently executing calls finish.

 

Is there something about the CCR that makes it more useful than WCF? Am I missing something?

 

There's a lot of concurrency management code examples using WCF up on Idesign.net http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11#ConcurrencyManagement

 

From what I understand of WCF it allows you to write multi-threaded .NET applications of any kind with the use of locks, monitors or semaphores.

All you have to do is add an attribute to the class implementing the service like so:

 

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall,UseSynchronizationContext = false)]

 

This may not be the correct setting but it gives you a general idea of how easy it is to implement concurrency in WCF.

 

Jonathan Parker

.NET Developer

Email: info@xxxxxxxxxxxxxxxxxxxxx Blog: www.jonathanparker.com.au

 

From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of ILT
Sent: Wednesday, 13 June 2007 5:27 PM
To: dotnet@xxxxxxxxxxx
Subject: [aus-dotnet] Has anyone used the CCR?

 

Following on from the Joel Pobar Perth session on concurrency, I came across CCR via a message post at CodeProject.

The CCR - Concurrency and Coordination Runtime for asynchronous processing (see here, for a description by Peter Blomberg) – may offer in the CCR.Core assembly (154Kb) some welcome help with threading and concurrency, beyond using the excellent BackgroundWorker control and a lot of brain-power for the more elaborate scenarios.

Unfortunately to get the 154K assembly it is necessary to download 50Mb of the Microsoft Robotics Studio May 2007 CTP.

Has anyone seen code / blog / more thorough descriptions? Or – better – used the assembly and compared its ease of use and applicability with roll-your-own management of threads and concurrency using eg the thread pool?

Here’s a description from Bromberg’s Unblog for those that are interested.

---

The central feature of the CCR is that it makes programming asynchronous behavior much simpler than the typical challenge of writing threaded code.

When an application's thread performs synchronous I/O requests, the application is giving up control of the thread's processing to the I/O device (a hard drive, a network, etc.). The application's responsiveness then becomes unpredictable. When threads are suspended waiting for I/O requests to complete, the application tends to create more threads in an attempt to accomplish more work. The problem is that creating, scheduling, and destroying a thread requires time and memory and can actually hurt performance rather than improve it.

The CCR offers a number of classes that provide the developer with a simple object model that you can use to express complex coordination patterns for dealing with completed I/O operations. CCR offers its own high-performance thread pool you can use to execute tasks in response to completed I/O. The thread pool offers great scalability, and when you couple the CCR with some of the new C# language features (such as anonymous methods and iterators), you have gotten an easy way to write more responsive and scalable applications.

With the CLR's thread pool, if 1,000 items are queued, there is no way for a new item to be processed until all of the first 1,000 items have been extracted from the thread pool's queue. With the CCR you can use one DispatcherQueue object for most work items and use another DispatcherQueue object for high-priority work items. The Dispatcher's threads dequeue entries from all the DispatcherQueue objects associated with it in a round-robin fashion, making your total processing much more efficient and scalable.

The Dispatcher class creates a Dispatcher object that creates and manages a set of threads. In effect, it is a thread pool. Like the CLR's thread pool, these threads call methods (via delegates) in order to execute tasks. Unlike the CLR's thread pool, there is no special thread that runs periodically checking the workload and trying to predict whether threads should be dynamically added or removed from the thread pool.

After you've created a Dispatcher, you'll construct a DispatcherQueue object. This maintains a queue of delegates that identify methods ready to execute. The Dispatcher's threads wait for entries to appear in the DispatcherQueue. As entries appear, Dispatcher threads wake up and execute the methods.

[ MORE ]

---

IL Thomas
GeoSciSoft  - Perth, Australia