Hi, On Friday, September 23, 2011 5:25:34 PM UTC+2, stuart....@gmail.com wrote: > > I would have hoped that changes to refs during an transaction wouldn't > affect the in-transaction value of the ref > > you usually don't want that. When you start working on more than one value in a transaction (and that's the point -- otherwise you'd use an atom) you will most probably want to use the in-transaction value like a "common" state-changing variable. It just feels more natural.
Imagine a genetic algorithm which creates new individuals and calculates their fitness in parallel. After one thread created a new indiv and computed the fitness it will want to save that indiv to The Population. However, there may be a monitor in place that also updates the list of the best 10 indivs in the population just within the same transaction. This might want to sort the new Population, including the new indiv, and return the best 10. Ah, words fail me... I think, my main point is: start using more than one Ref in a coordinated manner, because that's what they are for. Maybe you'll see. (And, of course, maybe you'll stick with your view ;-). > (that is, I would have > liked the code to print 1, then 2). This way, the view of the > program's state would always be guaranteed to be consistent, > > But you are creating a new consistent state in minor steps that you, in your code, know how to control, and that you want to be atomic *from the outside*. STM ensures that the changing of as many Refs as you need will appear atomic from outside the transaction. > even > during a transaction, and there would be no fear of non-consistent in- > transaction states breaking anything. The way it is currently work in > Clojure, though, still requires one to take all such inconsistent > states into account, rendering them effectively useless for the kind > of state management I imagined. > > I'd be interested in reading, what you want to achieve. > (Note that I am not talking about multi-threading here; my objective > is to reduce the number of possible states in the single-threaded > case, and make sure that every computation is based upon a consistent > state.) > > Huh? It is probably too late in my time-zone to fully understand, what you'd like to do. But why would you want to use a technology that was made to deal with state changes from different threads for guarding a single-threaded application? Kind regards, Stefan -- 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
