On Monday, December 10, 2012 3:15:04 PM UTC+1, Paul Butcher wrote: > > On 10 Dec 2012, at 13:37, Marko Topolnik <marko.t...@gmail.com<javascript:>> > 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. >
My thinking always assumes the existence---and prevalence---of lock-based concurrency. Problems with non-critical performance are usually not too hard to do with locks: just use some simple, coarse locking scheme. I'd need a quite convincing case where locks are an obvious disaster and an STM-based approach comes to rescue. These are hard to find, and personally I have tried several times to start out with STM, only to end up falling back to locks. -- 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
