Hi Kevin > I've worked with, and debugged, code written in several different > concurrency paradigms: > > Data-flow > Asynchronous / Futures / Continuation Passing > Actors > Software-Transactional memory > Shared state with locks & mutexes > Fork-Join > > and my experience mirrors Ricky's, shared state is by far the hardest to > reason about. > > By comparison, STM is probably the easiest to understand, Asynchronous is > the best performing, and Actors the most reliable. Data-flow and fork-join > aren't truly general purpose techniques, which makes them hard to categorise > in this fashion. > > Shared state *can* have a performance benefit, the LMAX disruptor shows this > clearly.
My understanding is they have a single threaded model, so the shared state doesn't really impact in their case. > But it also demonstrates the performance benefit of avoiding > locks - which can easily harm performance much more than GC pressure. This > is the same reason that the asynchronous model also performs so well, even > in the presence of immutable objects. I like Clojure's approach in that it generally only copies the small amount of data it needs. That said, if you 'need' to operate concurrently on all 1,000,000 elements in that data structure then yo'd best learn about GC tuning :-). Cheers, Martijn -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
