I want to +1 what Stuart said. In my research on the subject, almost every implementation of STM that allows for mutable-by-default data has ended up as a miserable failure.
Specifically see the results from Microsoft's research: http://www.infoq.com/news/2010/05/STM-Dropped Clojure's implementation of STM hinges on the fact that must data is immutable. Thus a transaction that reads 100 items from one ref and writes the results to two other refs, needs only track updates to 3 pointers instead of 103. The PyPy STM model is a bit different ( http://morepypy.blogspot.com/2012/05/stm-update-back-to-threads.html). Here they assume that all threads are serial (global lock) and then selectively enable STM in places where it is known that threads are unlikely to clobber each other's data. It has resulted in slight success, but that's mostly due to the fact that Python currently is locked to a single core, so any concurrency is better than nothing in that regard. That being said, the PyPy guys have a 10+ year history of proving scoffers wrong, so there's hope. So as Stuart said, it's worth pointing out that in a OO mutable-by-default language, STM is basically worthless. Timothy Baldridge On Tue, Dec 11, 2012 at 1:30 PM, Marko Topolnik <marko.topol...@gmail.com>wrote: > Just curious, how did you immediately eliminate the possibility that the > reducing function was mutating the list that is being reduced? No > concurrency involved. In regular Java the 95% leading cause of CME is > precisely that. > > Anyway, this applies to immutable structures per se, whether combined with > atoms, refs, or none. But a full wartime story must also cover how the > solution avoids the pitfalls of retryable transactions. This is the real > sore point in my experience, and the one which makes STM an all-or-nothing > enterprise. > > > On Tuesday, December 11, 2012 8:53:40 PM UTC+1, stuart....@gmail.comwrote: >> >> Hi Paul, >> >> Here is a real-world, production software example of the advantage of >> values+refs over mutable objects and locks. A Datomic user reported the >> following stack trace as a potential bug: >> >> 12:45:43.480 [qtp517338136-84] WARN c.v.a.s.p.e.UnknownExceptionH**andler >> - UnknownExceptionHandler: null >> java.util.ConcurrentModificati**onException: null >> at >> java.util.ArrayList$Itr.checkF**orComodification(ArrayList.**java:819) >> ~[na:1.7.0_07] >> at java.util.ArrayList$Itr.next(A**rrayList.java:791) >> ~[na:1.7.0_07] >> at clojure.core.protocols$fn_**_5871.invoke(protocols.clj:76) >> ~[clojure-1.4.0.jar:na] >> at >> clojure.core.protocols$fn_**_5828$G__5823__5841.invoke(pro**tocols.clj:13) >> ~[clojure-1.4.0.jar:na] >> at clojure.core$reduce.invoke(cor**e.clj:6030) >> ~[clojure-1.4.0.jar:na] >> >> I immediately had 99% confidence that the bug was in user code, and even >> a pretty good idea what went wrong. A call to "reduce" is a functional >> transformation, and it expects to be passed values. The exception clearly >> indicates a violation of that contract, and is caused by cross-thread >> aliasing and mutation in the calling code. >> >> Regards, >> Stu >> > -- > 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 > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
