i think it would be awesome if someone worked up a scenario . . . started using regular old java . . . and we could walk into a few gotchas, publicly/transparently, where a serious java guy could chime in ... and really see what the stm buys. Then we'd have an even richer appreciation for the STM model. Specifically, how learning STM is easier than learning concurrency as taught in a typical cs curriculum.
On Sun, Mar 22, 2009 at 10:12 PM, Mark Volkmann <r.mark.volkm...@gmail.com>wrote: > > I'm trying to understand the degree to which Clojure's STM provides > more concurrency than Java's blocking approach. I know it's difficult > to make generalizations and that specific applications need to be > measured, but I'll give it a go anyway. > > Clearly using STM (dosync with Refs) makes code easier to write than > using Java synchronization because you don't have to determine up > front which objects need to be locked. In the Clojure approach, > nothing is locked. Changes in the transaction happen to in-transaction > values and there is only a small amount of blocking that occurs at the > end of the transaction when changes are being committed. Score one for > Clojure! > > What concerns me though is how often the work done in two transactions > running in separate threads turns out to be useful work. It seems that > it will typically be the case that when two concurrent transactions > access the same Refs, one of them will commit and the other will > retry. The retry will discard the in-transaction changes that were > made to the Refs, essentially rendering the work it did of no value. > So there was increased concurrency, but not useful concurrency. > > Of course there is a chance that the transaction contains some > conditional logic that makes it so the Refs to be accessed aren't > always the same, but my speculation is that that's are rare > occurrence. It's probably more typical that a transaction always > accesses the same set of Refs every time it executes. > > This makes it seem that Java's locking approach isn't so bad. Well, > it's bad that I have to identify the objects to lock, but it's good > that it doesn't waste cycles doing work that will just be thrown away. > > I hope I'm missing some important details and will be set straight by > someone! > > -- > R. Mark Volkmann > Object Computing, Inc. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
