On Wed, Jul 1, 2009 at 1:50 AM, Krukow<karl.kru...@gmail.com> wrote: > > > On Jun 30, 6:01 pm, Rich Hickey <richhic...@gmail.com> wrote: >> MVCC history in Clojure's STM is dynamic, created by need. There is no >> read tracking, and more important for this case, no transaction >> tracking. So, if a read transaction is unable to satisfy its snapshot >> view from history, it will flag the offending ref with a fault and >> retry. When a writer sees a ref with a read fault it will grow history >> for that ref. In this way only as much history is created as is needed >> to satisfy the dynamic contention patterns, and >> tracking/synchronization is minimized. > > Ok - I understand better now. I guess I had an "idealized" system in > mind where each ref (in principle) had a complete history associated > with it so reads would never need to be retried (of course, unneeded > entries would somehow be discarded when the system decides it can > never be read.) Certainly that would imply tracking transactions. I > guess you don't do this because of the overhead. > > I like the pragmatics of :min-history, and I believe it would be > sufficient for many scenarios. However, I suspect we are now moving > closer to the situation that Cliff Click was predicting [1] where as a > programmer you need more precise knowledge about the STM > implementation to understand the behavior and tune its performance. >
Yes, ok, but the key questions are, how complex is it really, and, compared to what? Any large lock-based application will have an ad hoc lock policy approaching the complexity of Clojure's STM. Each programmer will have to learn the lock strategy of each program. And what happens when requirements or the hardware capabilities change? I'd much rather have knobs like :min-history than to have to go through an app and change a lock architecture that is woven throughout. In fact, I think the possibility for knobs is a key strength of an STM. Furthermore, such knobs can be dynamic, allowing for applications that analyze their own runtime situation and adapt, in this case trading off memory for concurrency. Try doing that with a lock policy. (I know you are not advocating for locks, but Cliff was). As usual, comparisons to GC hold. There are many flavors of GC, each with different characteristics. An app will have to choose the right flags, understanding the tradeoffs involved. It is still a lot better than manual memory management for most apps. At JavaOne I did a demo showing how an app could put its own runtime 'knob' on transaction granularity, to useful effect. A point I tried to make was that this was the level at which one wants to think about their concurrency issues. (Ok, fine, one would like magic that makes it all go away :) Thinking about what constitutes a unit of work, what are the contended resources etc. Being able to deal with that using 'knobs' on a system that is ensuring correctness seems like a huge win to me. So, certainly many of the things Cliff said are true, but are they negatives? You will have to understand the fundamental characteristics of your STM, and any knobs it provides. You will have to choose transaction boundaries. You will have to choose ref granularity. Ok. But absolutely nothing is going to make the fundamental issues of concurrency go away. The real question is, what facilities are provided for dealing with them, and how closely do they map to the nature of the problem? How much effort do you have to spend on correctness? What render is getting there is really a huge thing - a consistent snapshot of the world, that spans multiple entities, without holding up everyone else. I have yet to see a non-STM solution (that isn't an ad hoc STM or MVCC) that can provide the same. I'll try to expand upon "adaptive history queues", and the new knobs, in the docs so people can better understand what they imply. Rich --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
