[rosejn]

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...