> In the epic thread about the STM between Rich and Cliff Click[1] the > main argument against the STM was that it didn't help solve the problem > of where to place guards around the data. From one of Cliff's arguments: > > In a trivial example I can say �go up one call level and atomic > there�, > but in the Real Program � I can�t do that. > Go up how many layers and add atomic? 1 layer? 10 layers? 100 layers? > Yes, I see unique call-stacks > with >100 layers. I can�t put atomic around main because that makes my > program single-threaded. > > > I believe Cliff is arguing here that when a program pushes all of the > state into a single atom where a lot of writes occur that app > effectively is single-threaded. (Please correct me if I am > misunderstanding!) Thoughts? >
Actually, this is one of Cliff's weaker points. Note that when he says "atomic", he really means "dosync". He speaks from experience with HotSpot where this was a constant source of bugs. It doesn't translate directly into the same ptifalls with Clojure's STM because 1) Clojure has strict control on what needs a transaction to mutate and 2) the points of mutation are much more focused when you are dealing with immutable structures. Cliff's strongest argument comes from experience with MPI, where he raises very valid points against any implementation of a high-performance concurrent library: This is exactly the trap MPI fell into; and *you* have to do it anyways. > Double-unsmiley. :-( :-( > > Here’s the deal: > > I write a Large Complex Program, one that Really Needs STM to get it > right. > - But performance sucks. > - So I do a deep dive into the STM runtime, and discover it has > warts. > - So I hack my code to work around the warts in the STM. > - Crap like: at an average of 5 cpus in this atomic block the STM > ‘works’, but at an average of 7 cpus in the same atomic block I get a > continous fail/retry rate that’s so bad I might as well not bother. So I > guard the STM area with a “5-at-a-time” lock and a queue of threads > waiting > to enter. Bleah (been there; done that – for a DB not an STM but > same-in-priniciple situation). A thousand thousand variations of the same > crap happens, each requiring a different hack to my code to make it > performant. > - Meanwhile the STM author (You: Rich) hacks out some warts & hands me > a beta version. > - I hack my code to match the STM’s new behavior, and discover some > new warts. > > Back & Forth we go – and suddenly: my app’s “performance correctness” is > intimately tied to the exact STM implementation. Any change to the STM’s > behavior kills my performance – and you, Rich, have learned a lot about the > building of a robust good STM. You (now) know the mistakes you made and * > know*it’s time to restart the STM implementation from scratch. > On the other hand, this is a problem occuring only at the most demanding level of load on the code. People may still benefit from the STM to write simple, correct concurrent programs. As I already explained, in my experience atoms cover 98% of that need and locks are still unavoidable. If I wrote a whole system from scratch and based everything on the STM, *then* it could replace locks. This will never happen in a JDK-based Clojure. -- 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
