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