Concurrency's shysters

http://dtrace.org/blogs/bmc/2008/11/03/concurrencys-shysters/

by joubert • 16 years ago

42 27 16 years ago

lukev2• 16 years ago

He's kind of tilting at windmills, here. It's true that there's a lot of hype about concurrency, etc.

But take Clojure, which AFAIK is the only real system people are actually using that places STM front and center (except maybe something in Haskell land). Rich Hickey is the furthest thing possible from a shyster.

For example, he never claimed that STM is faster than manual locks, just that it's an order of magnitude easier to write correct programs - which seems to be borne out in actual experience. Yes, there's a not-insignificant overhead. But for most programs it's still probably worth it.

Similarly, the claim that STM isn't any good because most computational resources aren't memory is a complete red herring - STM is quite useful for memory management, and for other resources, well, find a different strategy. It doesn't stop STM from being quite useful in its domain.

All in all, this sounds more of a luddite rant than a reasoned opinion. It reminds me of what I've read of the initial objections to managed memory or even high-level languages themselves. Of course a lot of the technology isn't there yet. Of course a lot of it is going to be rabbit trails that ultimately don't deliver. It still doesn't mean it's not the future.

cageface6• 16 years ago

I don't think you can call one of the inventors of D-Trace a luddite, and the article was hardly a rant.

If you agree that many resources that require serial access are not memory then I also don't see how STM is making your life significantly easier. Composing locks and transactions in the same system sounds much harder to me than just using locks.

I think the jury is still out on the effectiveness of Clojure's concurrency model. It makes for nice short examples but I'm not aware of anything of any real complexity built on it yet.

lukev2• 16 years ago

I certainly didn't mean to insult the author of the article... I just meant that the tone of the article itself had the sort of curmudgeonly tone that a lot of really good system programmers have towards fancy new technologies in their infancy.

All I mean to say is, some of those fancy new technologies do grow up to become quite useful.

And STM is designed around memory access. If you're attempting to write a concurrent program, and you have heterogeneous resource types, shouldn't you use a strategy which is optimal for each one? An IO socket is a fundamentally different sort of thing than memory, and ought to be managed differently.

pmjordan• 16 years ago

the article was hardly a rant

You'll have to admit it's extremely thin on actual arguments. There are lots of links to journal publications, but it would have helped to summarise their actual findings rather than hand-wave about "complexity".

Composing locks and transactions in the same system sounds much harder to me than just using locks. I think the jury is still out on the effectiveness of Clojure's concurrency model.

Actually, Clojure does address that by allowing you to compose transactions with agents. If you send messages to agents during a transaction, they will only receive the messages sent from the transaction attempt that successfully completed. This leads to a fairly natural state-change-then-I/O pattern where the agent locks the non-memory resource and operates on it.

swannodette3• 16 years ago

Many of the arguments made here against STM (and in the linked papers) are nicely addressed by Clojure's specific implementation of STM. This article is from 2008, before Clojure was more widely known.

More importantly, Clojure is wisely designed with several other equally useful concurrency mechanisms: atoms for serial access, promises for dataflow, pmap for divide and conquer, and agents for uncoordinated concurrent activities.

rbranson• 16 years ago

Yeah, the same arguments against garbage collection. They are always leaky abstractions. It doesn't mean you can be a dumber programmer, it just means you can spend less time focused on problems ancillary to the core purpose of your software.

noelwelsh• 16 years ago

I disagree. I think the author is unjustifiably extrapolating conclusions from a C/kernel development world to the rest of software development. For example, a bunch of systems use the "green threads" model. Erlang SMP is one. Erlang SMP is unarguably successful. The referenced article on STM confuses parallelism with concurrency[1]. They test on a bunch of benchmarks that are mostly 1) not concurrent and 2) for performance rely on fast numeric operations that have a vastly different level of granularity to typical business ops.

[1] Parallelism = speeding things up by using multiple cores. Concurrency = modelling a system that naturally has different activities going on at once. These are not the same thing.

kscaldef3• 16 years ago

Erlang SMP is successful on one axis (ease of writing correct and reliable concurrent problems), but it seems to me that the argument in the article was about the performance costs of the model. And, at least as of a year or two ago, Erlang SMP did _not_ have good performance. There was a minimum factor of 2 overhead in total CPU usage just by turning on SMP, and heavily concurrent programs could run massively slower (http://shootout.alioth.debian.org/u64q/benchmark.php?test=ch...). At least part of the problem is that there's no affinity between Erlang processes and scheduler threads (and, therefore, CPU/cores), so you've got constant cache misses. There's probably other issues as well. As the author says, it's a hard problem.

gtani3• 16 years ago

stackoverflow shows recent BEAM and secret incantation (I haven't tried this yet, maybe tonite)

http://stackoverflow.com/questions/1996524/optimizing-perfor...

igouy2• 16 years ago

> There was a minimum factor of 2 overhead in total CPU usage just by turning on SMP

n-body without SMP 123.30s

n-body without SMP 123.30s elapsed

n-body with SMP 133.52s

n-body with SMP 133.57s elapsed

spectral-norm without SMP 46.68s

spectral-norm without SMP 46.68s elapsed

spectral-norm with SMP 47.71s

spectral-norm with SMP 13.90s elapsed

mandelbrot without SMP 230.07s

mandelbrot without SMP 230.10s elapsed

mandelbrot with SMP 253.66s

mandelbrot with SMP 87.76s elapsed

Maybe that Erlang chameneos-redux program is unusual?

kenjackson• 16 years ago

"I think the author is unjustifiably extrapolating conclusions from a C/kernel development world to the rest of software development. "

Exactly. This is the core problem with threading in real systems. Not that it's not possible, but it's not likely going to yield good results with your non-kernel devs. And unfortunately, given that processors are now getting most of the perf benefit by adding cores, this is a problem.

And his conclusions about two-level scheduling, IMO, should be tempered. For example, the lack of pre-emptability is something that I believe most user-level thread packages now deal with. Another issue he discusses is that under load, the kernel doesn't realize that there are 'm' degrees of parallelism. It only sees the LWP. But a good user-level threads package should work system-wide.

He also says that detachment and reattachment is more expensive than one might think. I'm curious if they looked at some of their contemporary work, like Cilk, to see how they handled this?

I actually think he did good work in his thesis. But it seems more like a snapshot of a particular implementation than a statement about the technology in general.

grogers2• 16 years ago

I haven't read his thesis, but more and more languages/environments are moving to two-level scheduling being the dominant way to get performance. When I read through it later I'll be interested to see how his results are applicable to the systems used in eg. Go, erlang, .NET, etc.

rosejn• 16 years ago

I found it interesting that in the post he criticizes previous discussion of lock based concurrency, while not providing anything close to the level of analysis that he apparently requires of his fellow disputant.

'“Locks are not modular and do not compose, and the association between locks and data is established mostly by convention.” Again, no data, no qualifiers, no study, no rationale, no evidence of experience trying to develop such systems...'

It is well known that lock based concurrent libraries do not compose, and anyone writing articles about concurrency should not require an explanation of this central issue in the discussion[1]. Of course with millions of hours of developer investment in a centrally managed codebase like Solaris it is possible to achieve incredible parallelism with locks, but that isn't practical for the vast majority of modern software, which continues to use ever more external libraries.

Clojure's STM paired with immutable data structures are an especially well suited combination that are unlike most of the research systems presented in this area. Of course there are additional resources that will have to be managed, such as access to I/O, but I would argue that access to I/O is by far the easier problem to deal with in comparison to concurrent access to memory - primarily because I/O devices are typically accessed serially so you can just queue up requests.

[1]: Here's one explanation with a code example of why locks don't compose: http://www.drdobbs.com/article/printableArticle.jhtml;jsessi...

Concurrency's shysters

Related Stories