Chillout Lounge

Disclaimer: Since it’s relatively new concept to digest, I’m gonna go slow and might repeat!

Well, if you were a computer science student like me, I’m sure you would have your own taste for Robots from the college/university you graduated to build world’s greatest(!) robot. I’ve tried hands-on to create few basic robots, sleep with those Fuzzy logic books as pillows, travel from library to library for more books on robotics, Butter up dad for the extra pocket money to buy robotics toolkits, quarrel with your friend in mid-night when everything breaks up and miraculously rebuild everything in shape at about 4 AM in the morning before the demo of the project that day well this was about a decade back… Everything around robotics world was little primitive but things have evolved now!

One such evolution is Microsoft Robotics Studio. More info at http://www.microsoft.com/robotics

The robotics studio helps you to create and control industrial robots or pretty much any kind of robot. Well, surprisingly looks like I still have the some quest that i had 10 years back and in the process of building a new robot using this. I will write a little more on this shortly.

But before that i would write about getting basics correct and some new thoughts as i started learning this framework in this multi-part article.

The objective of this article is to put new ideas/concept in your mind, to make you think about a fresh/new approach for building High Performance Computing & Distributed Software Solutions using Robotics.

Wait a minute… Robotics && (HPC + Distributed Computing) ? Do they really coerce? Don’t they sound two different opposite poles? Well, the truth is the Robotics World has evolved silently in parallel to the commercial software industry and has numerous technical inventions which are not being used in the main-stream commercial software computing.

The objective of this article is focused on something interesting, which is already creating ripples around the industry through its 2 new technological inventions – Concurrency and Coordination Runtime (CCR) and Decentralized Software Services (DSS).

Well, to begin with CCR was initially built for robots because robots are expected to respond for *Millions* of concurrent behaviors like touch, sound, color detection, visibility, motion sensors et al and CCR was built to cater these needs. But, once this framework was built, the inventors realized the real potential of this framework. That is, the CCR also addresses the need of mainstream software especially the High Performance computing needed by modern day web software’s, distributed systems and service-oriented applications to manage asynchronous operations, deal with concurrency, exploit parallel hardware and deal with partial failure. CCR is complemented with Decentralized Software Services (DSS) a lightweight .NET-based runtime environment that sits on top of the Concurrency and Coordination Runtime.

Decentralized Software Services (DSS) provides a lightweight, state-oriented service model that combines the notion of representational state transfer with a system-level approach for building high-performance, scalable applications.

Well, for those of you who do not like the definitions – here is the quick synopsis

CCR = Programming model for Multi-threading + inter-task synchronization i.e. think about some one magically removing those complex multi thread management code from your programs yet it runs perfectly multi-threaded! i.e. think about multi-threading without mutex, semaphores, deadlocks… does this ring the bell somewhere? read on..

DSS = Framework that allows to run your Services anywhere on the network.

Alright, by now if you would have questioned HOW? the answer is that we will be doing threading without Windows threading model. A Brand new threading infrastructure that enables multiple tasks to execute concurrently on a single computer.

And… how about executing these multiple tasks on completely separate computers and manage it centrally?

In short with CCR + DSS we will see linear scaling on high-volume data and high-transactional software’s in industries like Medicine, financial trading, scientific modeling, messaging systems or even increased scaling and concurrency on the enterprise search servers. This is possible because CCR manages asynchronous operations, exploit parallel hardware, deal concurrency and handle partial failure.

Figure 1: CCR Architecture

Now… Let’s get bit technical…

In Figure 1 I’ve tried to depict the architecture of CCR as I understand. The Dispatcher depicted in the end is the real critical piece which provides stunning scalability & maximizes concurrency in the application, rest of them are the object model that support the Dispatcher.

To begin with, the Portset is a FIFO queue of a Port. Port can be any valid CLR Type. The receiver manages it’s own queue and is code guarded by an “Arbiter”. The Arbiter is more like a gate keeper which actually filters the message and executing appropriate messages.

The dispatcher queue is the real load-balancer and scheduler of tasks, they also manage the data, execution and resources of these tasks.

The Boss of everything here is Dispatcher. The CLR Thread pool is a single and process wide execution resource. But, CCR allows *multiple* completely isolated pools of OS threads and completely *abstract* the complications of thread management from the programmer. i.e. you don’t have to worry about deadlocks, mutex et al anymore.

also, CCR allows to share a single dispatcher between hundreds of software components from heterogeneous networks, which can *load balance* thousands of tasks using a very handful number of threads.

Let’s explore DSS in-depth and a real time code example in Part 2 and Part 3