From Ocaml koans:

Michel Mauny was giving a guest lecture to new computer science students. After the students were seated, Michel pronounced “Today’s lecture will be about Lazy Evaluation”, he paused for a moment then concluded with, “Are there any questions?”

Luca Cardelli

I was reading one of Luca Cardelli’s more recent papers this evening. Luca did a lot of early work on the ML language at Edinburgh, including one of the earliest useful ML compilers. Plus he has a cool dijkstra font on his website too. 🙂

Anyway, back to the paper. It’s called “Modern Concurrency Abstractions for C#” (PDF). I got interested in concurrency stuff whilst at Ergnosis. I realised that while we have lots of language support for data abstraction and control-flow abstraction, we don’t have much support for concurrency abstraction. Coding using threads and mutexes is like coding in assembler. It’s very powerful, but there are a million and one ways to introduce bugs into your code. An assembler can’t tell you that you’ve made a type error, or failed to initialize a local variable. Similarly, a compiler can’t tell you that you’ve coded a potential deadlock or race-condition when you’re using threads.

I wouldn’t ever consider writing a big application in assembler, and similarly I don’t really want to write complex concurrent code using the crude low-level primitives provided by threads. It leads to untraceable bugs, loss of hair and late nights. That’s just so yesterday! So, I’m interested in abstractions for concurrency – things which wrap up the complexity and stop you shooting yourself in the foot. I want to work with bigger building blocks.

The paper describes two extensions to the C# language – asynchronous calls and “chords” which allow you to express how combinations of methods work together. The paper then goes on to demonstrate how these new language features can be used to express common concurrent programming idioms. For example, consider a simple one-element container. If the container is empty, calls to Get() should block until some other thread calls Put(). Likewise, calls to Put() should block until the container is emptied by calling Empty(). Chords are a language extension which allows you to express that these pairs of methods have dependencies on each other. Check out the paper for more details.

There’s a few things worth noting about the paper. Firstly, there’s a good discussion about why you sometimes want to add features to the language, rather than providing them in libraries. When you add language support (say, for concurrency) then the compiler can analyze the usage and warn if you’re doing dangerous stuff. If you have concurrency support in libraries (eg. mutexes) then the compiler can’t do any analysis on /how/ you are using it. An example of the latter approach is JCSP, an implementation of Communicating Sequential Processes for Java.

Secondly, I had a bit of a laugh at section 1.3 where he justifies why C# is the ideal testbed for this kind of stuff. I couldn’t help thinking that “because Microsoft pays the bills” is probably the primary reason. Especially when later in the paper he reveals how the prototype compiler for the extended language was written in ML!

Still, it’s nice to see efforts to add more powerful features into mainstream languages. There’s a huge amount of academic research into concurrency, but relatively little of it filters through into the kind of tools you’re likely to use in industry.

It’s an interesting paper and it’s very accessible compared to other more theoretical material about the join calculus and such like. And as an added bonus, my ex-Voxar collegue dnt gets a citation at the end.

Microsoft can boast an impressive array of researchers (heh, I have a languages bias) within their folds. And they feature in Uni labs too. Gosh, they’re even assimilating people I know!. But they’re all still producing papers, so it’s hardly the death knell of research as we know it. But, is the ever-increasing influence of industry over research healthy? I’ll don’t want to start getting all political and start ranting about this, but I’d be interested to hear from people with strong views either way.


I have finally written about my teleworking experiences. It’s just an ascii file tonight, straight out of emacs, but I’m too tired to make it look pretty just now.

My cool sounding job with the small startup fell through, due to them suffering cashflow problems. I feel quite sorry for them actually. Startups produce some of the coolest new ideas around. Financially, they often live a hand-to-mouth existence in their early stages. All it takes is for a big company to fail to pay on time, and that can throw a small companies financies into disarray, and sometimes on the road to bankruptcy. It’s plain wrong.

I’ve got several new interviews lined up over the coming week. I have really enjoyed taking December off to recharge my batteries. Part of the plan was to spend time doing non-computer stuff, and I’ve achieved that admirably. However, I’ll be a lot happier once I have something concrete sorted out on the job front.