4 ms·
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 peo
by lukev 16y 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.
- cageface 16y agoI 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.
- lukev 16y agoI 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.
- cageface 16y agoThe ACM article he links is worth a read. It discusses the pitfalls of STM in greater depth and includes some real-world benchmarks.
- pmjordan 16y agothe 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.
- cageface 16y agoYou'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". It's a blog post. What do you expect? The ACM article he links to is excellent, with some very in-depth analysis and real benchmark numbers showing exactly where the overhead of STM is most onerous.
- swannodette 16y agoMany 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.
- cageface 16y agoHow specifically does Clojure's STM implementation avoid the pitfalls outlined in the ACM paper? How many real-world benchmarks do we have demonstrating Clojure's concurrency scaling?
- swannodette 16y agoAn informative and lengthy discussion between two experts (Cliff Click of Azul Systems and Rich Hickey): http://www.azulsystems.com/blog/cliff-click/2008-05-27-clojure-stms-vs-locks http://www.azulsystems.com/blog/cliff-click/2008-05-27-cloju...
- cageface 16y agoAn interesting discussion but inconclusive. I agree with Rich that it would be very useful to have an established set of meaningful concurrency benchmarks. For example, I'd like to see if a Clojure solution of the benchmarks in the linked ACM paper can scale better than the solutions tested in the paper.
- swannodette 16y agoExcept those ACM microbenchmarks are exactly the kind of fine-grained problems Rich Hickey specifically stated he's not trying to solve. For example http://dosync.posterous.com/stm-couchdb-and-pushing-5500-documentssecond http://dosync.posterous.com/stm-couchdb-and-pushing-5500-doc.... I added only 7 lines of code. Raw Aleph runs at about 20k req/s on an 8 core box. This code performs at about 14-18k req/s. So clearly some contention is at play. I could write this with locks, but I have better ways to spend my time. That's the real cost-to-benefit ratio.
- rbranson 16y agoYeah, 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.