On Monday, December 10, 2012 1:56:08 PM UTC+1, Chas Emerick wrote: > > On Dec 10, 2012, at 5:39 AM, Marko Topolnik wrote: > > 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 >
The argument (b) is an even better fit (or, should we say, *perfect fit*) for Actors, as implemented in Erlang. > 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. send-off fails to be useful whenever you need the results within the transaction (quite often, that is). > > 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. But concurrency is *all* about performance and throughput. So where is the benefit of using correct, slow concurrent mutation? I guess in a write-seldom, read-often scenario. > 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. > Business logic almost always involves communication with outside systems (since it's usually about integration of many existing systems). Even if not, a scalable solution must be stateless (a prerequisite for cluster deployment) and any durable state must go into a single datasource common to all cluster nodes. Again, these datasources don't participate in an STM transaction. Maybe this would be a major route of improvement: integrate the STM with external datasource transactions. But this is still quite removed from the present. -- 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
