I'm surprised you're surprised. Whatever machinery involved: if multiple actors contend for the same memory location they will suffer. The best strategy is to distribute jobs, work on each of them independently on local resources, be it processor registers, thread locals, local memory or disks and to synchronize the results with others as infrequently as possible. It's the basic principle behind fork-join in a multi-threaded process and map-reduce on a large cluster. Nothing new that Gilad Bracha discovered in 2008, is it?
Matthias On Tue, Apr 8, 2008 at 7:25 PM, Martin Probst <[EMAIL PROTECTED]> wrote: > > >> Yeah, clever, and basically the same as the eventual fix I had for > >> JRuby > >> since it gives each thread its own counter. I think the primary rule > >> here is that don't expect any sort of unsynchronized, uncontrolled > >> updates to the same shared resource to either behave the way you > >> want or > >> perform the way you want. > > > > It may be a bit off-topic, but it's interesting how this argues for > > immutable data structures and Erlang's concurrency model. > > I guess once you're into concurrency, everything argues for immutable > data structures. > > It's also nice to see how this fits with Gilad Brachas arguments > against the Java 'static' keyword (which allows mutable structures to > be shared implicitly between threads), as Charles already noted. > > Regards, > Martin > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" 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/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
