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 -~----------~----~----~----~------~----~------~--~---