I’ve been getting a fair number of requests for my slides from last week’s keynote at OGDC. They’re now available here.
OGDC Talk Slides Online
Herb Sutter Concurrency 1 Minute
Published by Herb Sutter
Herb Sutter is an author and speaker, a software architect at Microsoft, and chair of the ISO C++ standards committee. View all posts by Herb Sutter
6 thoughts on “OGDC Talk Slides Online”
Sebastian and Hugh: Excellent questions. I’ll try to blog some longer answers to these in the future.
In the meantime, here are some very short answers.
Re memory model: Yes, and I’m working to define and document a standard memory model across all Microsoft platforms, and regularize some of the, ah, irregular facilities out there right now. This is being done in conjunction with the ISO C++0x memory model work; see my previous blog posts, or websearch for "Prism" and my name to see drafts.
Re Haskell: For a few thoughts, see the comments on functional languages in this paper I co-wrote with Jim Larus for ACM Queue.
I may have more to say soon.
From the threading performance standpoint, what is your opinion on Erlang threading model and user-threads (aka coroutines)?
Here’s a link showing how Erlang threading and coroutines beat pthreads:
And here’s a link showing how Yaws beats Apache
If I am reading things right, pthreads (or win32 threads for that matter) carry this heavy ball-and-chain of spawning a heawyweight OS process for each thread.
Is there anything that could be done for C++ to improve threading performance, or is counting on more cores/processors to bail us out the only strategy?
I was wondering what your thoughts were on languages like Haskell. I see you’ve already mentioned STM, which has a very good implementation in the Glasgow Haskell Compiler, and as far as I can tell solves the "elephant in the room" problem (IO isn’t transactional, so shouldn’t be allowed in an atomic block, and in Haskell the type system ensures this).
I seem to remember you mentioning the need to be able to markup parts of code which don’t have side effects in that Channel9 video. This too, seems to be solved already in Haskell. A modern Haskell programs have many "layers":
* IO: impure, anything goes
* STM: transactional references
* Purely functional code: Here’s the bulk of the program
* ST: Mutable state that can be encapsulated into little "nuggets" (by calling runST) which are statically ensured to not "leak" side effects and can therefore be used by pure code.
The final two layers can call each other, but other than that a layer can only call "down" in this list, which ensures that e.g. a function which doesn’t return an IO action won’t go off and call "launch_nukes()" in a transaction (which then gets rerun).
Now I personally don’t think Haskell comes all the way of solving all of this. For example, I make games for a living, and I find that laziness has a very real performance cost (though something like lenient evaluation may strike the right balance between modularity/expressiveness and speed). It also makes any possibility of an implicitly parallellising runtime much less likely. The point I’d like to make is this: It seems to me that the "right" way to go about this is to add mutable variables etc. in a safe "encapsulateable" way on top of a pure layer (see the ST monad), rather than trying to graft a pure layer on top of impure code (the result of which will likely be that nobody uses the pure layer). Haskell proves this concept to my satisfaction.
I think the ST monad is a bit clunky to work with, but there’s no reason why a language couldn’t provide some nice syntactic support for writing impure code with mutable state, which just compiles into something like the ST monad underneath, providing static guarantees that no side effects leak outside the ST type, and that you can therefor use algorithms with mutable state from pure code (important!). This syntax would be identical for transactions, and IO-actions as well.
The way I see it, Haskell gets it almost 100% right. I have a number of gripes with Haskell (laziness, the module system, lack of lightweight records, clunkiness of writing monadic code, etc.), but the main good ideas from Haskell (purity, strong static typing, ST monad for impure code wrapped up inside pure code, STM for when you really need low level shared state threading, etc.) could be borrowed and put inside a language which looks and feels a bit more like C++ (to avoid scaring people off too much!). That would, for me, be pretty much the ultimate language for the coming many-core future.
Comments are closed.