On Dec 10, 2012, at 5:39 AM, Marko Topolnik wrote: > The very fact that there has been no reply to this for five days may mean > something. I can personally attest to STM being very difficult to put to > real-life use because there is always that one thing you absolutely need for > your problem, that is mutable and not transactional. Most of the time it will > have to do with an existing Java library, JDK not excluded. The property of > STM that it is an all-or-nothing commitment has been a show-stopper for me > every time I tried to use it.
I'd be surprised if Paul doesn't hear from people directly; people aren't always keen to talk about their work publicly (and in many cases, they are simply barred from doing so), so one shouldn't presume that on-list responses (or not) are representative. I personally have never used STM in nontrivial ways (AFAIC), but that's due more to the demands of the problems I run into more than anything else. On the other hand, I have used, abused, and benefitted from agents in umpteen ways. Actually, I have often done things using agents that might otherwise been done using STM or other similar approaches, simply to ensure that: (a) the processing involved can be readily parallelized, and (b) if necessary, the system can be partitioned/distributed with minimal impact to the architecture, since — if you're careful about things — it doesn't matter whether a send is evaluated in an in-process agent or one housed in a different server/VM/whatever Yes, only a subset of the things you can do with STM can be done safely with agents, etc. (See: monotonic logic, and the increasingly-popular concepts of lattices, semilattices, and CRDTs.) But, I've been lucky to be able to characterize many problems within that subset. It's true that STM is "all or nothing", but it is so over the scope of refs you choose. If there's some side-effecting bit you need to do somewhere, then clearly that's not going to fit within a transaction…but that bit will often fit just fine in a send-off to an agent provoked _by_ a transaction. And, if you can implement e.g. 2 of the 5 parts of your system using refs and STM, you just cut your thread-and-locking problems by 40%. :-P > My guess is, if your task is something purely computational and amenable to > massive parallelization, you may have a go with STM; if it's just about > business logic accessible concurrently by many clients, you won't find it > workable. If your task is purely computational and amenable to massive parallelization, you _should_ use agents whenever possible. STM provides for coordination in order to enforce consistency; unless all of your operations are commutative (in which case, you should probably be using agents anyway), a program using STM _will_ provoke retries and other means to route around ref contention. This is acceptable because STM is all about maintaining correctness in the face of concurrent mutation, and not necessarily about performance, aggregate throughput, and so on. On the other hand, ref readers are _never_ blocked (regardless of what's going on on the write side), so the data in such refs is always accessible. This sounds like an ideal combination for "business logic" (as nebulous a term as that is) to me. Cheers, - Chas -- http://cemerick.com [Clojure Programming from O'Reilly](http://www.clojurebook.com) -- 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
