Introducing Maestro – A DSL for Actor Based Concurrency

As you may have noticed from my blog, there is a big interest in concurrency.  Along with that, I’ve made my way into Actor model based concurrency including such forays into Erlang, the Haskell-Actor package, Mailbox Processing in F#, and even such things as Retlang in C#.  The problem with some of the .NET solutions is that they don’t go far enough into memory isolation and channel contracts as to what can and cannot happen.  In order to enforce such a behavior, we need some sort of static analysis to indicate that.  Of course with static analysis, it could be ignored and might not be as type rich as, say a DSL.  And that’s where Maestro comes in.

Introducing Maestro

Earlier when I first started heavily down the Erlang path towards message based concurrency, the ideas of memory isolation through the use of actors was important.  To disallow reference leaks between processes, this type of isolation is needed  Seeing such efforts in the .NET space as Sing#, which brought such concepts as Software Isolated Processes (SIPs) and Channel-Based Contracts even drove the point home even more in order to have a scalable and fail-safe application, this type of behavior is required.  And even more, have a language that supports such concepts.  In past efforts, I have tried implementing my own versions of what they are trying to do, but running into issues of having AppDomains as isolation units are clumsy and heavy-weight.  Also, of course I’ve used a bit of Erlang, but to me, it’s not a very beautiful language with awkward syntax as opposed to more pleasing syntax of say Haskell, but of course beauty is in the eye of the beholder.

So, what is Maestro?  Simply put, it’s a Domain Specific Language for agent based concurrency on the .NET platform.  In a post on the Maestro Team Blog, in the entry “We haven’t forgotten about other models – honest!”, Josh Phillips, the Maestro Program Manager goes over some of the basic details.  There is also a Channel9 interview with Niklas Gustafsson, the language architect and Artur Laksberg, a developer which is also highly worth watching twice, as well as a Dr. Dobb’s Journal article as well.

Simply put, Maestro is not just another general purpose object oriented  language for .NET, but instead a subset of language features which allow for easier isolation and concurrency within that isolation.  You could think of it more as a actor-oriented language instead with constructs for model coordination and message passing between components.  Built upon Concurrency and Coordination Runtime (CCR), this is a powerful language which speaks to the following points:

  • Process Isolation
    Each component is an isolated machine that works in parallel and does not share resources.  Any inter-component communication must be communicated through an explicit request and a narrow channel.  Think channels and channel contracts.
  • Message Passing
    In order to enable the communication between isolated components, a concept such as message passing can be used to express this.  In order to communicate, typically we serialize the message contents and send to the subscriber.  If light-weight, they can be a highly scalable approach to concurrency.
  • Fault Tolerance
    Typically, in shared-state applications, detecting and dealing with concurrency and failure is a complex task.  However, if we work in isolated state, any potential failure can be limited to the component.  When such a component fails, other components can be notified by either a master process or through timeouts or some other mechanism, and restart the process.
  • Loose Coupling
    When designing for reuse and maintainability, using shared state concurrent components can be difficult due to the exacting nature of knowing about locks, mutexes, semaphores and so on.  Instead, with message passing and isolation, components can interact with each other through narrowly defined channel contracts.  With this isolation, the components inner implementation can be refactored without any impact on the calling system.

But, what about the language itself?  How does it work?

Breaking down the language, here are some basic building blocks of the language:

  • Agents
    An isolation concept which interact with each other with message passing over defined channels with asynchronous or synchronous behavior.
  • Channels
    Defined ports in which data is passed from between components.  These channels define what can and cannot happen on this channel through the use of Channel Contracts.  These ideas are very similar to the ideas from Sing#, the language from the Singularity Operating System.
  • Domains
    A larger concept than agents in which they are isolated from all other domains and can have nested agents.  Each agent can have access to the domain state, but in a controlled fashion.
  • Schemas
    In order to communicate between domains, agents, etc, we need to define the data transfer type definitions, also called schemas.  These schemas define the structure and behavior for the data passed between isolated components.
  • Networks
    In order to express how we can communicate, we have defined interaction points which we can build into networks.  This allows for the definition of data flows within an agent or domain.

What does the code look like?  Taking a page from the Maestro Team Blog, we can define domain D1 with an agent A1 with a channel type of C1, which receives a message from its primary channel.  Then we do some more work and then sent the value 10 as the result as follows:

domain D1

    object obj = new object();
    string str = "Hello!";

    agent A1 : channel C1
            var startWith = receive(PrimaryChannel::FirstMessage); 
            // Some calculation
            PrimaryChannel::Result <– 10;

There are a few more examples worth noting on the Maestro Team Blog.

A Call To Action

So, you may be asking about where you can get your hands on it today.  If you will note from their blog, there is a title on the left hand side which indicates the following:

Maestro is an incubation technology and Microsoft has not committed to shipping it.

So, in other words, at this moment, there is no firm commitment from Microsoft to ship this as a product.  But, if you are interested in this as a product, please do let Microsoft know.  Your voices do matter in whether this becomes a product or not.  Stay tuned to the Maestro Team Blog for more news as it becomes available.

This entry was posted in Concurrency, DSLs, Language Oriented Programming. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Chris Patterson


    I realize that there are major issues with concurrency patterns in existing languages on the CLR. Even in Maestro, you have to the choice to define domains (which are likely AppDomains) for non-shared memory. I think you can also use shared memory (faster, no serialization required) with the honor system of “I ain’t gonna change it”.

    I’m going to sit and watch and hopefully see something come out. But being able to use this type of system mixed-in with my existing C# business logic would make it an easier sell in the end. Just some feedback, I realize there are other issues at hand.

  • Matthew.Podwysocki


    I had been researching this a bit more before I mentioned it. Also, since it has no commitment from Microsoft to ship the product, so in terms of near near term, it’s not quite the now solution.

    Why a language? Because current languages don’t deal with concurrency and asynchronous behavior in a fairly standard fashion. The memory isolation issue is huge in that we can guarantee no references can be shared between isolated processes. With a library approach we could only do so much, and then only have static verification to enforce behavior. Of course following these FxCop or CodeContract rules are optional in a way, this makes it more useful for extensibility and to serve more as a glue DSL and not just a general language.

    Well, I’m working on going deeper as is the team and hopefully you’ll see more from the team blog and hopefully here on the lower level details.

  • Chris Patterson

    I find this interesting since I just asked you last week if you knew of any actor frameworks for .NET — who knew.

    I’d be interested in seeing how this goes, but honestly why does this have to be another language? I realize given the current design of C# and the style of locking inherent in that platform, it’s going to be tough to ensure a clear separation of actors. Maybe I’m just making too many assumptions up front though.

    I’d be interested in seeing at a deeper level how they are implementing this. Considering Scala actors were built on top of the JVM, it should be possible to do something similar with some version of the CLR.

    Count me as one tick in the “interested” column.