Microsoft CCR and DDS, Part 1

After presenting the Concurrency and Coordination Runtime (CCR) and Decentralized Software Services (DSS) Toolkit at the PDC08, Microsoft released it as commercially available product. Originally, the toolkit is part of the Robotics tool selection and frameworks. This week now the current version was released, Microsoft Robotics Developer Studio 2008, as free, downloadable, Express and normal Standard edition. Part of it is the CCR as well as the DSS library, also Microsoft Visual Programming Language is part of the package. The runtime libraries can not be redistributed, for this you have to by the seperate product bundle, but for playing around with the new toolkit this is more than sufficient.
The first interesting part is the CCR. There are three main components:
Ports which provide a type safe, atomic data interface. Arbiters on the other side are responsible for coordination and the execution of the user code. The last interesting piece are the Dispatcher and the DispatcherQueue, responsible to actually react on data posted at a port. Data can be posted to a port and either a Arbiter schedules the execution of a specific user code section provided by a delegate with the help of the Dispatcher. The important thing is, that all calls are atomic and is thread safe, so there is no need for locks. Basically it works conceptually like message passing. The CCR is very well documented and provides the basic structure for the DSS and most of the Robotics services. One interesting concept is how iterators are used to handle the asynchron program workflow. For this a small code example which uses them for reading a file can demonstrate this:

IEnumerator FileReadEnumerator(string filename)
    // this is the port which is responsible for handling the 
    // IAsyncResult structure
    var resultPort = new Port();

    // open the synchron file read stream, and this is important: inside
    // a dispose block
    using (FileStream fs = new FileStream(filename,
        FileMode.Open, FileAccess.Read, FileShare.Read, 8192,
        Byte[] data = new Byte[fs.Length];

        // start reading from the file, the port post function is used
        // as callback
        fs.BeginRead(data, 0, data.Length, resultPort.Post, null);

        // the second important thing: the iterator suspends until the port
        // gets data, meaning that asynchron processing has finished. A
        // empty delegate will be executed at this event
        yield return Arbiter.Receive(false, resultPort, delegate { });

        // get the actual asynchron result structure for closing the port
        var ar = (IAsyncResult) resultPort;
            Int32 bytesRead = fs.EndRead(ar);
            // handle I/O exception

This implicit iterator is now called by the following code snippet:

Dispatcher dispatcher = new Dispatcher();
DispatcherQueue taskQueue = new DispatcherQueue("Default", dispatcher);
    Arbiter.FromIteratorHandler(() => FileReadEnumerator(@"C:\test.txt")));

The arbiter is using the handles the delegation to the actual file reading logic and works in non-blocking mode, the iterator is responsible for the actual program flow. The beauty of this code is that the program flow in in one, optical, sequential flow and has some important advantages
instead of using anonymous delegates. For one thing the using() ensures that the file stream actually gets correctly closed while not using delegates it is possible to use parameters and local variables which can lead to problems otherwise.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: