I just started reading through that article a couple days ago and a couple things jumped out at me right away with respect to Clojure. The most important, it seems, is that the STM system in Clojure is not the concurrency hammer for the language, immutable data structures are. All of the articles I've read in opposition to TM focus on the current performance overhead that they all tack on, which is fair. (Although it is clearly still relatively early days in the research and dismissing TM now because of its current performance characteristics is just foolish ... more research is necessary.) However, comparing the performance of a mutable state, lock-based system and a mutable state, TM-based system has nothing whatsoever to do with Clojure.
If Clojure's TM system tacks on a 20% overhead (note, I just made that number up), that can pretty safely be ignored. The reason is that you are only using TM for 20% of your concurrency support, if that. The immutable data structures do the rest of the work for you with great performance characteristics. Immutable data structures are the jack hammer of Clojure's concurrency support. The STM is more like a ball-peen hammer [1], taking care of the cases where shared state is, indeed, necessary. Regards, - J. [1] http://en.wikipedia.org/wiki/Ball-peen_hammer On Tue, Nov 4, 2008 at 3:47 AM, Christian Vest Hansen <[EMAIL PROTECTED]> wrote: > > Just reading through the first CACM article, they raise a number of > issues that I think are more addressed in Clojure than they give > credit to TMs in general based on whatever implementation they were > investigating. > > I present my feeble attempt to join the TM debate: > >> TM introduces a variety of programming issues that >> are not present in lock-basedmutual exclusion. >> For example, semantics are muddled by: >> * Interaction with non-transactional codes, >> including access to shared data from outside >> of a transaction (tolerating weak atomicity) >> and the use of locks inside a transaction >> (breaking isolation to make locking operations >> visible outside transactions); > > The referencing part is at least clearly defined: outside a > transaction, the refs are read-only. > > Locking is a different beast. While true that it is a side-effect that > will creep to the outside world, I don't see how a lock inside a > transaction is bad in any way that a lock outside a transaction is > not. (But they might have yet to tell me since still not through with > the paper.) > >> * Exceptions and serializability: how to handle >> exceptions and propagate consistent exception >> information from within a transactional context, >> and how to guarantee that transactional execution >> respects a correct ordering of operations; > > A consistent snapshot of the world is presented inside a transaction. > Exceptions and serialization will be based on that world view. > > I don't get what they mean by correct ordering of operations. Ordering > inside a transaction would matter just as much as it does in a > single-threaded scenario, would it not? > >> * Interaction with code that cannot be >> transactionalized, due to either communication >> with other threads or a requirement barring >> speculation; > > Just don't do that. Transactions are not a silver bullet. Use an agent > instead. > >> * Livelock, or the system guarantee that all >> transactions make progress even in the >> presence of conflicts. > > True, TMs don't solve this for you. Just like locking doesn't solve > deadlocks for you. > > A key assumption of the paper seems to be that TMs are the solution to > all things concurrency. But perhaps this is exactly the myth they are > trying to debunk? > > My view is that TMs are another tool in the box, just like CAS, locks, > agents, volatile, thread-locals, immutables, atomics and all the rest > of java.util.concurrent. And I believe that people who think that > magical mechanism to solve all concurrency woes will drop in their > lap, are wrong and will (with high probability) be proven so > (hopefully before their systems go live). > > On Tue, Nov 4, 2008 at 8:50 AM, srnm <[EMAIL PROTECTED]> wrote: >> >> http://blogs.sun.com/bmc/entry/concurrency_s_shysters >> >> I'm new to clojure... and like what I see. >> >> Just passing this blog post on as a discussion point... >> >> Thanks! >> >> >> > >> > > > > -- > Venlig hilsen / Kind regards, > Christian Vest Hansen. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
