We have seriously examined the possibility of releasing the source code under an OSS license, but that, too, will require time that we don’t have that much of. At this time, no one is assigned paid hours to work on Axum, but we are still entertaining fantasies about an open-source release sometime in the future by doing some extra work during down times.

That said, the incubation effort was very successful in our opinion: several of the concepts embodied in Axum live on in the next versions of C# and .NET: C# and VB will support their own form of asynchronous methods, while .NET is adding support for data-flow constructs following the patterns we set up in Axum and the C++ concurrency runtime.

On the other hand, the concepts around safe parallelism and agent-based programming were seen by many as too far outside the mainstream to be adopted now in languages like C# and VB. The idea of Axum was to not force these concepts on general-purpose languages, so those of us who have work on Axum are not surprised.

It’s disappointing to have to post this kind of entry, but it’s better to acknowledge the situation than to stick our heads in the sand and pretend that everything’s OK.

Niklas, Artur & Josh
Axumites

Since our last release, we were mostly involved in other projects, not the least of which is helping the rest of the team ship Visual Studio 2010. Now that the product is out the door, we were able to devote more effort to Axum, and today I’m happy to announce the availability of the latest release of Axum on DevLabs.

The main thrust of this release is making Axum language service (this is the component responsible for the syntax colorization and Intellisense) compatible with the Visual Studio 2010 RTM. We also fixed a few minor issues, but the language itself has remained largely unchanged.

This release is important to us because we want to keep your feedback coming. We also want you to get Visual Studio 2010 – not only will you be able to evaluate Axum, you will get your hands on such technologies as the Concurrency Runtime and the Parallel Extensions to .NET.

Artur Laksberg,
Axumite

Axum was, and still is, an incubation effort. What incubation means at Microsoft is something between research and product development: the aim is not to advance the state of the art, as we do with basic research, nor is it to ship a product in a timely manner. Rather, the purpose of doing an incubation is to assess the feasibility and viability of a technology when market research methodologies aren’t likely to be sufficient: there is no commitment to productize, but there is more to it than just throwing ideas over the wall.

Thus, we developed Axum and got the technology out there in the DevLabs release last year, updated it once, and you haven’t seen anything since.

Shipping a new programming language means committing to many years of maintaining it, so it’s something we would want to make sure we’re doing the right way. The question of what to do with it is on our minds: do we ship it in Visual Studio, should it be a separate release, should we just steal from it and integrate ideas into other languages? Should we find a narrower field that it addresses particularly well (discrete-event simulation, for example) and tailor it for that domain, or is this a more broadly applicable model? (I think it is, but that’s not the point: what our customers think is what matters here.)

Since June last year, we haven’t been idle: there was only three of us on the project to begin with, and now there are two, but both Artur and I are also working on other projects. We have been prototyping integrating Axum concepts into other languages, and we’ve been speaking about Axum, both within Microsoft and externally.

There hasn’t been much in terms of updates to the model, but we have some clear ideas on what we would need to take a closer look at if we productize it:

1. The language runtime needs a complete revamp – it is much too large and complex. We’d probably take a dependency on .NET 4 and give up backward compatibility in the interest of simplicity.
   
2. The parser has pretty awful, often misleading, error messages. We would have to rewrite it.
   
3. I would remove the declared network construct as well as the syntactic support for ‘sync,’ ‘async’ and ‘const’ variables – the semantics would still be there, but in the form of classes only.
   
4. Network expressions – the current set of infix network operators isn’t very extensible. We would revamp this area of the language.
   
5. Syntax for constructing and deconstructing tuple values – one thing I have appreciated in both C++ and F# is how easy it is to use structural types in the form of tuples. This is particularly useful for messaging where ports only take one payload type – make the payload a tuple and, voila! .NET 4 has Tuple as a built-in type: all we need is some syntactic support and we’re off…
   
6. Discriminated unions – we’ve experimented with what Axum would look like if ML were the syntactic basis instead of C. One concrete learning is that discriminated unions make channel declarations so much simpler and we should definitely add them to Axum.
   
7. Schema instances would be immutable. Coercing to other types give you mutability on a pay-for-play basis.
   
8. We would take a closer look at whether the domain and agent concepts can somehow be merged into a single concept without loss of expressiveness.

There are probably more things that need attention, but those are the ones that come to mind right now.

At PDC 2009, I did a breakout session on Axum, which was attended by about 250 people and received very well. For those of you who understand Swedish, I did a podcast with MSDN Radio in Sweden (which made me painfully aware of how hard it is for me to speak about technology in my native tongue. Ouch!).

Three weeks ago, I spoke about Axum at three universities in Denmark: Aarhus, Aalborg, and Copenhagen, and was pleasantly surprised when a customer I visited in Copenhagen wanted to talk about Axum. I had come prepared to talk about other parallel technologies, but they wanted me to do the Axum presentation, too, and they wanted to know what was going to happen to the language. They felt it was a perfect fit for their problems.

I also did an interview with a Danish IT journalist while in Copenhagen, and what she wanted to talk about was Axum.

Next week, I have a session on Axum at TechDays 2010 in Örebro, Sweden. This is a IT-centric show, so it’ll be interesting to see how Axum is received in comparison with PDC, which has a slightly different audience, more ISV-centric. It could go either way, I guess. There, too, I’ll be doing a couple of press interviews on Axum.

Anyway, I have promised to make a renewed effort to the DevLabs Forum for Axum and we will take a look at whether producing a release of Axum that is compatible with the final release of VS 2010 makes sense.

Thanks,

Niklas Gustafsson

Niklas Gustafsson, the Principal Architect on Axum (and some other jewels like the Parallel Extensions to the .NET Framework and the Concurrency Runtime) will be giving a talk on Axum in the Innovation Track (here’s a link to the session’s abstract)!  The date hasn’t been set yet, but keep your eyes peeled for updates.

Also, while you’re there, make sure to check out some of the other parallel computing sessions:

• The State of Parallel Programming (by supercomputing luminary Burton Smith)
• Patterns of Parallel Programming: A Tutorial on Fundamental Patterns and Practices for Parallelism (by Richard Ciapala, Ade Miller, Herb Sutter, and our very own Stephen Toub)
• Manycore and the Microsoft .NET Framework 4: A Match Made in Microsoft Visual Studio 2010 (by Stephen Toub)
• PLINQ: LINQ, but Faster! (by Igor Ostrovsky and Ed Essey)
• F# for Parallel and Asynchronous Programming (by Luke Hoban)
• Manycore and the Microsoft .NET Framework 4: A Match Made in Microsoft Visual Studio 2010 (by Rick Molloy)
• Lighting up Windows Server 2008 R2 Using the ConcRT on UMS (by Dana Groff)

Leave us a comment and let us know if you’ll be attending this year. :)

Josh Phillips
Program Manager and Axumite

Some of the more interesting highlights/discussion points I’ve pulled from the article:

• The language itself is only part of the draw for Erlang users.  The OTP framework provides great value to those writing distributed applications. “Since the restart functionality is already found in the standard library, no extra code was required to be written.”  What parts of the OTP do you feel are essential?  What’s missing?
• It reiterates some of Erlang’s flaws (we’ve heard lots of complaints about syntax).  I read this as a major opportunity for us to provide a highly differentiated solution and increase developer productivity (which is what Visual Studio is all about!).  “Erlang is not the perfect platform.  It has its share of weaknesses and most of it comes from the design goals behind the language.”  What else besides syntax and the lack of true string data types gets in your way?
• Performance comparisons.  WOW.  The performance gains on quad-cores are simply incredible.  100% CPU efficiency and a 3750% increase in MAX capacity per machine.  These numbers show major cost savings  for our customers.  Of course, it all depends on the baseline of which you are comparing against but I think it’s a safe assumption that Yahoo!’s developers are capable of writing fairly scalable, fairly performant code. 
• It’s interesting to note that they’re using Erlang “successfully” in 5 properties.  We’re seeing a lot more commercial products written entirely in Erlang or with components written in Erlang.  Some other noteworthy examples include Amazon, Facebook Chat, and Microsoft’s own PowerSet.  This trend suggests that companies are willing to overcome the learning curve and employ once-obscure technologies to achieve performance gains and, ultimately, cost savings in both hardware scale-down and developer productivity. 

Josh

Great stuff – thanks Matt!

The Axum Team

It’s been a while since we’ve last talked but many of you have silently been downloading the bits and surely some of you have actually been using them.  As we get further along in our prototyping/planning efforts we want to know how you’ve put Axum to work and what it’s done for you.

What have you built? We’re even interested in hearing about your toy apps. 

Did Axum benefit you?  If so, how? 

Tell us what the single most painful part of you experience was. 

Did you have an epitomic point where the agents model just made sense?

If you haven’t built anything, what would you want to build?  If you have, what do you plan to build next?

Keep experimenting!  We have a series of thought-provoking blog posts coming soon.

Josh
Program Manager, Axum

Axumites,

We’ve heard our customers’ frustrations with asynchronous programming and their call for improved support.  We are hoping to better understand why and how you and your customers use asynchronous programming in .NET and how the support we provide for it can be improved in the future.

We invite you to complete a short survey on the Asynchronous Programming Model (APM) as well as on a theoretical language construct called “Asynchronous Methods.”  Completing this survey shouldn’t take more than 5-10 minutes of your time, and doing so will help us to better understand where the APM is lacking, how we can make asynchronous programming better and, ultimately, how we can increase your productivity and the scalability and reliability of your code. We encourage you to forward this message on to others who may also have had experience with asynchronous programming.

https://deploy.ztelligence.com/start/index.jsp?PIN=15TMLTB8M3X9C

Thank you!

Josh Phillips | Program Manager II

We thought so.  We’ve been listening to some of your pain points with Axum 0.1.0 and went straight to the kitchen to cook up 0.2.0 - now available for your code-slingin’ pleasure.  We’ve fixed quite a few bugs and made some overall improvements. For example we’ve,

• Added an installer for Visual Studio 2010 Beta1
  
• Enabled parallel execution of functional nodes in dataflow networks
  
• Made it possible to change fonts and colors of Axum language elements via Tools | Options | Fonts and Colors
  
• Moved samples to a zip file to make using them easier
  
• Introduced AxumLite.zip – an Axum command line compiler that doesn't require Visual Studio
  
• Fixed the compiler error where the channel name was the same as the enclosing namespace name
  
• Made handling of immutable primitive types more rigorous; fixed some side-effect related bugs
  
• Added 'using System.Concurrency.Messaging' to the VS-generated template to make classes like OrderedInteractionPoint visible by default
  
• Added the async method Microsoft.Axum.IO.Console.ReadLine
  
• Added a spiffy Auction sample (A big shout out to Matthew Podwysocki for his help!)

Remember, Axum’s success and ability to improve your developer toolkit is very much dependent on your feedback.  Please try it, abuse it, and be very vocal about what you think on the forum.  We love to hear both good and bad things!

Axum 0.2.0 for Visual Studio 2008
Axum 0.2.0 for Visual Studio 2010
Axum Lite

Josh Phillips and the Axum Team

It’s been two weeks since we released the CTP on DevLabs. Thousands of people have downloaded it, tried it out, and many have sent us their feedback – thanks for all your input! In the coming weeks we will be releasing a new build that will contain some bug fixes and a few suggested improvements.

One of the features that gets a lot of attention is asynchronous methods. This is what allows us to have thousands and thousands of concurrently running agents without a significant memory footprint. This is what allows us to build responsive IO-heavy applications. It is also a good way to explain how cooperative multitasking works in Axum.

Let’s start with a sample application that I was writing the other day for some other blog post:

agent MainAgent : channel Microsoft.Axum.Application
{
    public MainAgent()
    {
        var pt = new OrderedInteractionPoint<int>();
        
        // Set up a dataflow network
        pt ==> MultiplyByTwo ==> Print;
        
        // Send some numbers to the network
        for(int i=0; i<5; i++) pt <-- i;
        
        PrimaryChannel::Done <-- Signal.Value;
    }
    
    int MultiplyByTwo(int n)
    {
        return n*2;
    }
    
    void Print(int n)
    {
        Console.WriteLine(n);
    }        
}

Before you copy it to Visual Studio, compile and run it – quick, what should be the output of the program?

I was trying to demonstrate that the elements of the dataflow network come out of it in the same order as they were put in. The program was supposed to send five numbers through the pipeline and get back the resulting numbers in the right order.

You might be surprised to discover that the program finishes without printing any numbers. Actually, it’s not hard to see why – the agent sends a message to the Done port before the dataflow network gets around to process the numbers. As soon as the runtime receives a message on the Done port, it terminates the application – sayonara!

If you’re like me, you might be tempted to try to “pause” the agent by putting a call to Console.ReadLine before sending a message to the port Done:

// Send some numbers to the network
for(int i=0; i<5; i++) pt <-- i;

// Not so fast! Wait until the user hits 
// return before continuing
Console.WriteLine("Press Enter to continue...");
Console.ReadLine();

PrimaryChannel::Done <-- Signal.Value;

Maybe you already see the problem but I didn’t. When I compiled and ran the program, it dutifully asked me to press Enter, which I did, after which it again terminated without printing any numbers!

That’s where it gets interesting.

Because MultiplyByTwo and Print are methods defined in the agent, they cannot run in parallel with each other or with the agent constructor. If they could, they would be able to modify an agent field, resulting in a data race.

For the two methods to execute, the constructor needs to explicitly suspend its execution and give other methods a chance to execute. In other words, it has to cooperatively yield.

In Axum, all methods have to acquire certain permissions before they can start executing concurrently. A method that can mutate domain’s state needs that domain’s writer token; a method defined in an agent needs that agent’s writer token. A method defined in an agent that is defined in a domain needs both tokens. Read-only methods (called true functions in Axum) require reader tokens for the corresponding domain and/or agent. Only one writer token exists per agent or domain, while multiple reader tokens are available.

This might seem complex but the implementation is actually quite straightforward and cheap. The tokens are stored in the TLS and don’t need to be passed from method to method, and there aren’t that many situations where the tokens need to change ownership.

One such situation is calling an asynchronous method, such as receive. When the receive is called and the message isn’t immediately available, the method pauses and releases its tokens to whoever is the next in line to acquire them.

For an asynchronous method, that pause is implemented as a return to the caller, and all the way to the thread pool if all the methods in the call stack are asynchronous. The rest of the method is then transformed by the compiler to run as a continuation.

By the way, I think that the term “asynchronous” to describe such methods is somewhat unfortunate – perhaps a better term would be “pausable” or “restartable” – because the ability to pause and restart is what these methods are all about. As if this were not confusing enough, we also picked different keywords for the experimental C# – ­async – and Axum – asynchronous. (We could not use the async keyword in Axum because it was already used for something else)

Both the experimental C# and the Axum compiler recognize the methods defined with the async/asynchronous modifier, as well as the APM methods, and treat them similarly.

Speaking of the APM methods – if you’ve used the .NET StreamReader class before, you must have noticed that it does not have the APM counterparts of the synchronous methods such as Read, ReadLine etc. Reading a text file line by line is not trivial – you have to read blocks of bytes, finding newlines among them and maintaining the current character position in the buffer so that the next invocation could pick up where the last one left off. Try to do it asynchronously and the complexity quickly becomes unmanageable.

The problem is solved trivially using the asynchronous methods – all you need to do is take the implementation of the TextReader, StreamReader, TextWriter and StreamWriter and sprinkle the methods with the async modifier. That’s all it took for us to make the synchronous methods asynchronous! These classes are now available in the Microsoft.Axum.IO namespace.

This is how the asynchronous ReadLine can be implemented using the classes from the Microsoft.Axum.IO namespace:

using Microsoft.Axum.IO;
public isolated static class AsyncConsole
{
    public async static string ReadLine()
    {
        var reader = 
            new StreamReader(
                System.Console.OpenStandardInput());
        return reader.ReadLine();
    }
}

Now the call site looks like this:

// Send some numbers to the network
for(int i=0; i<5; i++) pt <-- i;

// Not so fast! Wait until the user hits
// return before continuing
Console.WriteLine("Press Enter to continue...");
AsyncConsole.ReadLine();
        
PrimaryChannel::Done <-- Signal.Value;

Finally, this works correctly and prints out the numbers 0, 2, 4, 6, and 8, as expected.

The next build of the Axum CTP will contain the new Console class – look for it in the Microsoft.Axum.IO namespace.

Artur Laksberg