A Quick Overview of Microsoft’s Secret Parallel Library Project

Discover the original core of System.Threading namespace

Eduard Melu
Fabrit Global
7 min readApr 16, 2021

--

In the era of technology, things move fast, very fast, frameworks and technologies are constantly evolving.

Some of them are dying and new ones are born. Microsoft is in the top 10 when it comes to frameworks and new technologies and they appear to grow as the years pass.

Since speed is the key, parallel and concurrent paradigms are always the most wanted, so Microsoft came up with the System.Threading namespace.

In this namespace there is the Task Parallel Library which offers a way to write multithreaded and parallel code as safely as possible. But the root of this namespace and library was something called the Maestro project (later renamed Axum).

In this article, I will dive into the namespace and try to find the parallel model and concept that was designed in Maestro.

The Rise and Fall of Maestro

As I was talking before, speed is always the key in this era, so the parallel and concurrent solutions were like the holy grail.

Microsoft decided to join the race to perfect the art of parallelism and they came up with Maestro.

Maestro was a project that appeared in 2009 and was promising a new .NET language for parallel programming. The language was revolving around message passing and agents. Maestro was a domain-specific language based on the Actor model that targets the CLR. It focuses on making concurrency fundamental with principles of isolation, agents, and message-passing. [1].

The first documentation of this project was released to the public on 27th February 2009 and it presented the concepts behind the project.

On this project worked Josh Phillips (PM), Niklas Gustafsson (Architect), and Artur Laksberg (Developer).

In the beginning, it received a fair share of criticism because some of the ideas behind it have already been described in the Erlang programming language since 1986 (it was created by Swedish researchers that were working for Ericsson to support massive throughput under highly concurrent load) [3].

On 3rd February 2009 the project was renamed Axum and from that point on that was the final name of the project. The Axum project lived until 2011 when it was shut down. The principles behind it were condensed and integrated into the new Task Parallel library and later absorbed by the System.Threading namespace.

So basically, the parallel language proposed by Maestro stands at the core of System.Threading namespace.

General Presentation of the Model

Axum was the solution that Microsoft came up with in order to resolve the shared state problems and they wanted to avoid explicit thread synchronization.

Axum is based on the Actor model. In this model the actor (or Agent in Axum’s case) is the universal primitive of concurrent computation. It runs on the philosophy that everything is an actor, like the way some so object-oriented programming languages perceive an object.

The agent waits for a message to send messages to other agents, create new agents or control the behavior chosen for the next message it receives. The catch is that they can modify their private state, but they are unable to interact with other agents without messages.

All the operations done in the local (private) state can be done in parallel.

Because of this isolation of the agents, the parallelization paradigm doesn’t require lock-based synchronization.

Another key part of the way the agents can interact with each other. They don’t have a shared state and they run on the message passing to send messages and communicate, even though Axum offers something called a channel.

The message passing is like a trigger for an actor and relies on the actor’s infrastructure to execute and finish the task without any external intervention.[4]

Maestro is built on CCR which stands for Concurrency and Coordination Runtime and it’s a .NET library that includes a Dispatcher class that under the hood implements a thread pool with a fixed number of threads.

A DispatcherQueue that is just a queue of delegates representing the entry point of a work item.

The result is consumed for each work item with the help of a ReceiverTask object and it’s supervised by Arbiter that invokes them when the result is ready to be put on the port.[5]

Erlang Comparison

As I mentioned before, Erlang was considered a source of inspiration for the project since they are both actor-oriented models.

However, there are many things that Axum does differently.

For example, Erlang achieves isolation through the immutability of its data structures, Axum through scope-based isolation and making object graphs non-reachable. Erlang follows the traditional mailbox-processor actor design pattern, while Axum uses channels that are more like stay-alive HTTP sessions [8].

So the only thing that they have in common is that they are both focused on actors with the affinity of message passing.

In Depth Analysis of Parallelism

Niklas Gustafsson (the Architect) of Maestro Project refers to the model as being inspired by web applications.

So, let’s break down each component that makes Maestro what it is: At the core we have something called Domains.

They represent the core feature of the project since they are the key to isolation. They are limiting the run-time scope of data to its compile-time scope. Meaning that the objects inside a certain domain won’t escape.

Domains | Image by Author

As the diagram above shows, the domain can contain a group of shared data structures, but it isolates the rest of the resources.

Inside a domain we do have a shared state, but it acts as a barrier that stops outside-of-domain sources from modifying the data structures that are inside.

This concept being like how web services work where certain services can work independently while communicating through messages

Agents inside domains | Image by Author

So, another key concept is that of an Agent that lives inside a domain and is interacting with the shared state after he receives a message.

If an agent receives a write message, he will modify the data structure of that domain according to the instructions. However only on Write agent can work at the time.

On the other hand, if we are talking about read agents they can work inside of the model in a parallel fashion. The advantage here is that the agents can be written in a sequential fashion but run in parallel.

The agents communicate through a channel that is basically just a group of CCR ports. That are spited into input and output ports. Input ports allow you to send data and output ports allow you to receive data.[6]

Channels between Agents | Image by Author

Communication between agents through channels can be seen as symmetric since one can only send data through the send port and the other receives data through the output port.

The language also allows a user to define a protocol that will be designed as a state machine on each channel.

The last concept is the Schema that offers a way of communication between agents that have no relationship. In the diagram above, we can see all the concepts that we were talking about in one place.

Axum principles [7]

A code example of Axum would be:

domain A {
int i;
int func(int k) {}
writer agent X: Channel1 {}
reader agent Y: Channel2{}
}
domain B {
int j;
agent Z: Channel1 {}
}

Advantages and Disadvantages

As I said before, Maestro was inspired by the web model, so from the start it reduces the complexity of any program because of the isolation principle by cutting the number of dependencies between agents.

By doing this, completely removing the need for traditional concurrency control solutions. This can also scale incredibly well since it mimics the web model, and as we’ve seen so far, the web has not failed.

This does not mean that the Maestro model offers a perfect solution since, for example, it can wait for a message from another domain but inside that domain there’s been an error. So, it’s like a deadlock.

But the good part is that the web has already provided solutions for this kind of problem.

Conclusions

This article took a leap back in time in order to understand the roots of some popular libraries from .NET and explained the concepts behind the System.Threading library.

The fact that the whole model can be associated with the web itself is incredible and even though the project was never released to the public it helped the .NET framework by setting a path for it to follow.

Parallelism is something that we meet every day even though we are not aware so I hop I managed to explain the concepts in a good and easy way. Please let me know what you think!

Bibliography

  1. Maestro: A Managed Domain Specific Language for Concurrent Programming” Niklas Gustafsson MDSN DevLabs
  2. https://docs.microsoft.com/en-us/archive/blogs/maestroteam/dataflowprogramming-with-maestro Retrieved 2021–04–12
  3. Armstrong, Joe (2007). “A history of Erlang”. Proceedings of the third ACM SIGPLAN conference on History of programming languages — HOPL III. pp. 6–1. doi:10.1145/1238844.1238850. ISBN 978–1–59593–766–7. S2CID 555765.
  4. Goldberg, Adele; David Robson (1989). Smalltalk-80 The Language. Addison Wesley. pp. 5–16. ISBN 0–201–13688–0.
  5. MSRDS 2008 R3 Release Notes (MSDN Library)
  6. https://channel9.msdn.com/shows/Going+Deep/Maestro-A-Managed-DomainSpecific-Language-For-Concurrent-Programming/ Retrieved 2021–04–13
  7. https://www.infoq.com/news/2009/04/Axum/ Retrieved 2021–04–13
  8. https://social.msdn.microsoft.com/Forums/en-US/b031a7e6-53da-49ba-9f31- 2ec4d576c4aa/axum-amp-erlang?forum=axum Retrieved 2021–04–13

--

--

Eduard Melu
Fabrit Global

Hello there, Web Development and Big Data topics without the fuzz 🤘