Post Format

Multithreading: Don’t do it!

Strange Loop 2012

It seems that I mostly get to write a blog entry when I have been to a conference. This year I went to Strange Loop. Impressive. It is organized by Alex Miller (you might know his hilarious Maven Adoption Curve) – mostly in his spare time! It still feels like a small conference, even though there were more than 900 participants. It is a mixture of straight stuff like Brendan Eich’s tour de force of all new features and changes in the next JavaScript (EcmaScript) version (ES6). And stranger stuff like Daniel Spiewaks “Deconstructing P vs NP (or why I hate Sudoku)”.

There was the usual (in this case rather unsuccessful) attempt to explain Monads – at least the presenter did not help me understand them (I now think Monads were only invented so that blogger and conference speakers have a topic; there are probably more attempts to explain monads than there are programming languages. Or perhaps monads were invented in the same vein as C++).

I must admit that there were quite some bad presentations, but strangely the mood and atmosphere were so positive and there were so many good sessions, that I simply sat there and tried to get a grip on the stuff of the previous session (or simply went to get the next Espresso).

When I had to choose one thread that was presented in many talks it would be:

Multithreading: Don’t do it!

From the Disruptor to Node.js and Michael Stonebreaker’s Session on VoltDB (see below).

Multi threading is hard. You might even get it right for now. But when the system grows and other programmers need to change parts of your code, things get ugly. And they get ugly fast. You might introduce a subtle race condition so that customers could see the data of other customers (guilty as charged). I have yet to create a deadlock in production code, but a colleague of mine had to track down a deadlock in my code, which was caused by someone else using my code in a totally unexpected way (local calls instead of remote calls were the main culprit). Call me a bad programmer, but I know of many more examples (I deliberately only chose my own blunders).

Michael Stonebreaker is still creating databases. He was (one of) the driving forces behind Ingres and PostGres. Now he is working on an in-memory-database: VoltDB, which sounds quite impressive. And I liked his opinionated take on the NoSQL trend. I do not agree with him, but I like a well argued new perspective. He has worked such a long time in the world of relational databases, that he might not see the full picture. I do not think that these new ‘kids’ will replace relational (SQL, ACID, etc.) databases, but I think NoSQL fills an important niche.

If you could not attend: all sessions have been recorded and many of them should show up on InfoQ over the next months.

My personal favorite was a presentation by Chris Granger of Light Table fame. Light Table is a new kind of programmer’s editor. Trying to keep everything “at hand”. He took his inspiration from an intensive user study he did while at Microsoft (working as program manager for Visual Studio) and from Bret Victor’s seminal talk Inventing on principle (If you haven’t seen it: you really should). Bret did a variation of his talk at Strange Loop as well, but he seemed not as focused as in the presentation I linked to.

The funniest presentation was again about a new editor. Kind of. Gary Bernhardt showed a new editor that worked in the terminal (like Vim and Emacs), but did quite astonishing stuff. Even some UML graphs created on the fly with GraphViz. But to be able to display images in the terminal he even had to create a new terminal. Which is about as scary as it gets, since terminals are very low level stuff (kernel intergration and all). So it was kind of a let down (but of the funny kind) when he admitted that everything was a lie. A lie to demonstrate how much we are kept locked up in some notion of the 70ies about what a terminal is (and should be).

If you do not know Gary Bernhardt, please take a look at Wat. Brendan Eich (see above) even used the Wat guffaws to demonstrate some of the new features of the next JavaScript standard.

2 Comments Join the Conversation

  1. Multithreading: Don’t do it!

    I’m missing the alternative here. Sounds like my parents, when I was a child, prohibiting me the most interesting things, without explaining why not and how to do it better.
    So the how is well explained and evident, but what to do alternatively?
    Doing it all sequentially and accepting bad performance? – not really ;-)

    As Kennedy said: “We choose to go…not because [it is] easy, but because [it is] hard, because that goal will serve to measure and organize the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win.”


    • Michael!

      Thank you for the comment. You are right the alternatives are not explained only the names are mentioned.

      Node.js uses a single threaded event loop. I/O is not done by waiting and switching to another thread. Instead a callback is registered and the next event is handled. This has advantages and disadvantages, but it avoids thread context switching (good for performance and resource consumption in many cases; and it almost completely avoids deadlocks and race conditions — you can still shoot yourself in the food)

      The Disruptor uses a central ring buffer that (which is synchronized and may be used by multiple threads). But every writer and reader to/from this ring buffer must be single threaded. Therefore your own code again avoids many of the perils of multithreaded programming

      I do not know enough about VoltDB, but Michale Stonebreaker explained that they avoid multithreading. Instead the database is (automatically) sharded, so that you do not have to take care of the distribution. Neither when inserting nor when retrieving. I am not sure, how this exactly works, but still they are trying to avoid multithreading wherever possible


Leave a Reply

Required fields are marked *.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s