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

[Bill McCarthy]

"Disappear" isn't the goal, rather letting a framework deal with them is.
Take the example of LINQ and PLINQ. You couldn't do that (or not as easily)
if you for example wrote a custom iterator (e.g. "yield").  Having a
framework do it for you means letting go of the step by step control ;)
 

> -----Original Message-----
> From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of ILT
> Sent: Thursday, June 14, 2007 12:07 AM
> To: dotnet@xxxxxxxxxxx
> Subject: RE: [aus-dotnet] Has anyone used the CCR?
> 
> Yes, WCF of course (damned stupid acronyms). And I misspelled Bromberg
> a
> couple of times.
> 
> I think you're kidding yourself if you reckon declarative style
> programming
> will make concurrency problems disappear.
> 
> IL Thomas
> GeoSciSoft - Perth, Australia
> 
> -----Original Message-----
> From: peter@xxxxxxxxxxx [mailto:peter@xxxxxxxxxxx] On Behalf Of Bill
> McCarthy
> Sent: Wednesday, June 13, 2007 8:17 PM
> To: dotnet@xxxxxxxxxxx
> Subject: RE: [aus-dotnet] Has anyone used the CCR?
> 
> 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.
> 
> 
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.472 / Virus Database: 269.8.15/845 - Release Date:
> 12/06/2007
> 6:39 AM
> 
> _________________
> 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.


_________________
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.