Concurrency and Erlang

I gave a talk titled Concurrency and Erlang at Linux.conf.au in January, 2007. Thank you so much to everybody who attended it and made me feel welcome: I got overwhelmingly positive feedback from it, and it was an honour to speak at such an esteemed conference. This also serves as a homepage for the very similar Erlang and Concurrency talk that I gave to the Sydney Linux Users’ Group (SLUG) in July 2006, since the two talks were more-or-less the same.

View the official talk homepage on the Linux.conf.au site.

Download the (annotated) slides in PDF format (~9.5MB). Note: These slides are slightly more updated than the official ones that I gave to the Linux.conf.au committee.

Resources and Links

Talk-Specific Stuff

Wikipedia’s information about Tim Sweeney’s Unreal Engine series, which powers a pretty extraordinary list of games, from first-person shooters to massively multiplayer online role-playing games. Small plug: BioShock and Mass Effect, two games I’m so hanging out for in 2007, use the Unreal Engine 3.

The Company of Heroes E3 Trailer and in-game engine demo, which I showed briefly during my talk. zomgwtf that’s some fantastic graphics.

Concurrency and General Programming Articles

Software Transactional Memory, or STM, is the last bastion of hope for people who, for whatever reason, must still use shared mutable state in concurrency. Wikipedia has a great introductory page about it, and Simon Peyton-Jones has the best papers about it. STM’s still a very active research topic so it’s not recommended you use it in production work unless you’re really confident with it, but it’s a promising future direction for shared-state concurrency.

Simon Peyton Jones’s STM page has a lot of links to his research.

page has a lot of links to his research. There’s also a new draft paper named Beautiful Concurrency that Simon’s working on.

Added on 08/02/2007: Patrick Logan rips software transactional memory to shreds in a blog posting. His most valid point is that STM is basically untested right now, whereas message-passing and share-nothing concurrency has been used successfully in many systems for many years. Don’t take the article’s opinion as gospel, though! Yes, Patrick’s a smart and experienced developer, but Cale Gibbard (who responds in the comments to the article) is also a smart guy, and Simon Peyton Jones, a leader in STM research, is a very smart guy—as is Tim Sweeney, who supports STM and has his fair share of experience with threading issues. Read the article and be aware of the issue, though. Given the choice, I’d personally prefer share-nothing and message-passing vs transactional memory, but the two aren’t really mutually exclusive. (You can implement message-passing on top of STM, if you like.)

Added on 09/02/2007: The Lambda the Ultimate community discusses Patrick Logan’s post about STM (intelligently, as usual).

Erlang

Here’s some Erlang tutorials:

… and here’s some general articles about Erlang:

C

You have the choice of either using real kernel-level threads in C, or using a library that implements purely userspace threading (like Erlang, a.k.a. green threads). Userspace threads are very appealing since they’re so cheap and they arguably interact better with system libraries (a lot of which simply aren’t threadsafe), but unfortunately a big reason to use concurrency in C is to have background threads that perform I/O, which userspace threads don’t help you with at all since you’re still running one user process (from the point of view of the kernel) for all your threads. It’s not very hard to write a lightweight message-passing implementation in C, though: just email me if you’d like some details on how to do this. (In GUI applications, it’s really easy: just send a new event back to the main loop, and let the main thread pick it up and distribute the event to whatever thread should handle it.)

Protothreads for C.

GNU Pth (a.k.a. GNU portable threads), which implements userspace threading in a fairly portable library.

In general, Google around for protothreads, user-space threads, green threads, and actors in combination with C, libraries and the like to search for more interesting C libraries.

Objective-C

(This section added on 22/02/2007).

Here’s an implementation of Protothreads for Objective-C.

I’m very grateful to one of my readers for a pointer to an implementation of Erlang-style message queues for Objective-C: each thread has its own message queue, and sending to another thread’s message queue is asynchronus for the sending process. The receiving process can process the messages at their leisure. (Of course, I only found out about this after spending a day writing my own implementation of thread-local message queues… Murphy’s Law strikes again!)

Note that Mac OS X 10.5 (Leopard) will augment the very useful -[NSObject performSelectorOnMainThread:withObject:waitUntilDone:] method with a bunch of new methods to perform selectors on other threads besides the main thread. But, uhh, don’t tell anybody, because I think that’s information under NDA right now or something. (Ssssh.)

C++

Java

An introductory article about JavaSpaces.

I’ve also heard some good things about Jini, Sun’s Java networking that can be used as a message-passing infrastructure to build applications on. I don’t know enough about it to judge whether it’d be useful at all or not, so check it out yourself and see!

Python

The Stackless Python Homepage, which adds Erlang-style message passing to Python.

An excellent Introduction to Concurrent Programming with Stackless Python.

Note: I did some informal benchmarks with Stackless Python, and the runtime turned out to be pretty good indeed: it was roughly 4-5x slower than Erlang on code that achieved similar goals. (Note that this is actually quite a compliment: Erlang’s messaging system is, as you’d expect, bloody fast.) I think it’d be more than feasible to use Stackless in heavily concurrent projects.

JavaScript

(This section added on 15/02/2007.)

Brendan Eich quoted as saying “Threads will be added to JavaScript over my dead body” (along with one of his mates saying “I’d rather eat glass”; snigger). Interestingly, he declares that JavaScript 3 “will be ready for the multicore desktop workload”. Let’s hope that JavaScript 3 fixes the rather bizarre implicit type conversion semantics too…

Haskell

(This section added on 03/02/2007.)

Haskell has all of the same primitives and ingredients that Erlang has to support pure userspace threading and message-passing. Arguably, Haskell could be an even better choice than Erlang in the future for two reasons. First, it’s actually possible to omit threading from the core language and add it via a library (as some people have already done), which means that you can choice your threading model at your pleasure: kernel threads? Userspace threads? It’s up to you. Second, the type system can be used to check invariants and concurrency properties if you wield it correctly, and also forces a very clear separation of functions that do and do not manipulate state. GHC already supports many concurrency primitives (including the MVar , the nicest sort of mutable state primitive that I’ve seen yet), including using a combination of purely userspace threads with kernel threads.

I haven’t done any threading in Haskell for a long time and no doubt the state-of-the-art has moved very forward in the past few years, so Google around and check out the Haskell wiki yourself: there’s bound to be a plethora of information out there. Keep in mind that Software Transactional Memory is also in Haskell!

Blogs and good programming language sites:

Patrick Logan often talks about concurrency and distributed programming issues, and has insightful comments on everything from Python to LISP, Erlang, Smalltalk and Java.

Erlang, Smalltalk and Java. Lambda the Ultimate is an excellent site about programming languages that has an enormous number of interesting threads covering everything from concurrency issues to type systems.

gamearchitect.net has a lot of interesting articles on dealing with the complexity problems faced by games programmers, including a few about concurrency.

And, of course, there’s my own blog, where I write a whole bunch of my own opinionated crap about coding.

Redux

There’s a lot of information that I wanted to disseminate during the talk, but there’s just not enough time in 30 minutes to talk about too much stuff! A few people commented that I was making Erlang out to be the best thing ever. Please don’t take it that way: I’ve had experience with quite a few languages (C, C++, Python, Ruby, Erlang, Haskell, Objective-C) and all of them have their place and merits. Erlang is a stellar choice for writing highly distributed or concurrent applications, or for anything to do with network servers. Due to its lack of good GUI bindings, I wouldn’t use it for a normal desktop application unless the domain’s really quite specialised: stick with a more mainstream language for that kind of app, though still try to avoid shared-state concurrency if possible!

If there’s anything you’d like me to clarify or ask about at all, please feel free to email me via the link at the bottom of this page.