On 10 Dec 2012, at 13:37, Marko Topolnik <marko.topol...@gmail.com> wrote:
> 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. I'm not at all sure that that's true. There are plenty of occasions where concurrency is about being able to do more than one thing at a time, and not necessarily about making something faster. For example, your mobile 'phone is concurrent because, while it's playing music to you, it also wants to notice when you poke the screen and listen for incoming calls/messages from the network. And your IDE is concurrent so that it can check the syntax of your code in the background while the UI remains responsive. I'm not, of course, saying that performance isn't important - even in cases such as the above. It would be a major problem if everything was an order of magnitude slower just because I tried to do two things at the same time. But there are certainly plenty of occasions where we might choose to write concurrent code without our focus being on performance per-se. -- paul.butcher->msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher MSN: p...@paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher On 10 Dec 2012, at 13:37, Marko Topolnik <marko.topol...@gmail.com> wrote: > > > 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 -- 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
