Code for this post is available here. See below for the link to the download containing the CCR DLL.So here’s the problem: you need an in-memory queue in your application that can handle processing a large number (several thousands) of messages per second, using several enqueuing and dequeuing threads. If you’re using .NET Framework 4.0 then you would immediately go for the new ConcurrentQueue class available in the System.Collections.Concrurent namespace. But what if you’re not using 4.0? Well, you could download the Reactive Extensions for .NET and get a back-ported (and unsupported) version of Parallel Extensions for .NET 3.5 that contains this class. But there are other options.
Enter the CCRThe Concurrency & Coordination Runtime (CCR) is a little-known gem contained in the Microsoft Robotics Toolkit (available here as a downloadable express version). It supplies the developer with a rich set of abstractions that make it possible to write concurrent and asynchronous programs (the kind that drive robots with a bunch of sensors) in a coherent manner. Among one of these abstractions is Port<T> – the CCR’s version of the thread-safe queue. The port is the essential building block of the CCR – everything you do eventually boils down to reading and writing messages on a port, so naturally it has to be fast. A complete description of the various possibilities and capabilities of the CCR is outside the scope of this post – but it’s well worth your while to read the material here and Nick’s series here. If there is sufficient interest, I might do some more posts on it.
Back to BusinessOK, so we’re using .NET 4.0, including all the cool new concurrent collections and parallel task stuff. But what we want is SPEED. Should we even bother with the CCR if we don’t need any of the coordination primitives? This is what I set out to discover. Read more: Yuval Mazor
Enter the CCRThe Concurrency & Coordination Runtime (CCR) is a little-known gem contained in the Microsoft Robotics Toolkit (available here as a downloadable express version). It supplies the developer with a rich set of abstractions that make it possible to write concurrent and asynchronous programs (the kind that drive robots with a bunch of sensors) in a coherent manner. Among one of these abstractions is Port<T> – the CCR’s version of the thread-safe queue. The port is the essential building block of the CCR – everything you do eventually boils down to reading and writing messages on a port, so naturally it has to be fast. A complete description of the various possibilities and capabilities of the CCR is outside the scope of this post – but it’s well worth your while to read the material here and Nick’s series here. If there is sufficient interest, I might do some more posts on it.
Back to BusinessOK, so we’re using .NET 4.0, including all the cool new concurrent collections and parallel task stuff. But what we want is SPEED. Should we even bother with the CCR if we don’t need any of the coordination primitives? This is what I set out to discover. Read more: Yuval Mazor
Posts
0 comments:
Post a Comment