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

[Bill McCarthy]

Surely you meant WCF, not WPF.  The key to dealing with concurrency is
actually not having to deal with it. That is, if you use declarative style
programming that says what you want, rather than how/when to do it, then the
chances of a framework determining that and dealing with that for you are
drastically improved. Given that, I would rank WPF and LINQ as major steps
forward to dealing with concurrency and multiprocessors et al.


> -----Original Message-----
> From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of ILT
> Sent: Wednesday, June 13, 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
> <http://wallstreetandtech.com/video/02.jhtml> ").
> 
> 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
> <http://www.codeproject.com/csharp/ProcessQueue.asp?df=100&forumid=3406
> 53&select=1675968#xx1675968xx> .
> 
> The CCR - Concurrency and Coordination Runtime for asynchronous
> processing (see here <http://petesbloggerama.blogspot.com/2007/04/ccr-
> concurrency-and-coordination.html> , 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 <http://msdn2.microsoft.com/en-
> us/library/c8dcext2.aspx>  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


_________________
You are a part of the Australian "dotnet" mailing list. To unsubscribe send "unsubscribe dotnet" or to re-subscribe send "subscribe dotnet" in the body of the email to: imailsrv@xxxxxxxxxxxx For assistance with this list please email info@xxxxxxxxxxxx
List Managed by www.stanski.com and Proudly Sponsored by www.ico.com.au.