5 ms·

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 20

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.

cageface 16y ago
How 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 ago
  An 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 ago
    An 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 ago
      Except 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.
      - cageface 16y ago
        Stuffing a bunch of things into a DB in parallel doesn't seem like a very interesting problem to solve to me. As discussed earlier, Clojure's concurrency primitives are only useful for a somewhat specific class of problems: computationally intensive tasks in a single shared memory space. The benchmarks in the ACM paper seem to me to have a lot more to do with the kinds of complex datastructures you're going to employ in those scenarios than batching writes to a key-value store.
    - gtani 16y ago
      tehse 2 posts were useful in thinking about taxonomies/how to categorize concurrent/ threaded (and data parallel) tasks http://blog.ezyang.com/2010/07/graphs-not-grids/ http://blog.ezyang.com/2010/07/graphs-not-grids/ http://www.bluebytesoftware.com/blog/2010/07/12/ThoughtsOnImmutabilityAndConcurrency.aspx http://www.bluebytesoftware.com/blog/2010/07/12/ThoughtsOnIm...
  - runT1ME 16y ago
    I think Cliff Click pretty much makes the best case in that argument that for complicated problems, STM doesn't offer a lot more than regular locks.

cageface 16y ago

How 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 ago
An 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 ago
  An 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 ago
    Except 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.
    - cageface 16y ago
      Stuffing a bunch of things into a DB in parallel doesn't seem like a very interesting problem to solve to me. As discussed earlier, Clojure's concurrency primitives are only useful for a somewhat specific class of problems: computationally intensive tasks in a single shared memory space. The benchmarks in the ACM paper seem to me to have a lot more to do with the kinds of complex datastructures you're going to employ in those scenarios than batching writes to a key-value store.
  - gtani 16y ago
    tehse 2 posts were useful in thinking about taxonomies/how to categorize concurrent/ threaded (and data parallel) tasks http://blog.ezyang.com/2010/07/graphs-not-grids/ http://blog.ezyang.com/2010/07/graphs-not-grids/ http://www.bluebytesoftware.com/blog/2010/07/12/ThoughtsOnImmutabilityAndConcurrency.aspx http://www.bluebytesoftware.com/blog/2010/07/12/ThoughtsOnIm...
- runT1ME 16y ago
  I think Cliff Click pretty much makes the best case in that argument that for complicated problems, STM doesn't offer a lot more than regular locks.