On Mon, Apr 7, 2008 at 8:17 AM, Charles Oliver Nutter < [EMAIL PROTECTED]> wrote:
> > hlovatt wrote: > > This is a very interesting discussion and reveals a lot about the > > difficulties of programming for multiple cores. > > > > I was trying to understand what was going on and was 'messing about' > > with the code and I noticed that almost any change I made slowed the > > code down considerably - more than the 1 or 2 thread options in Java 6 > > does. Therefore I am not sure how realistic the code is. If the code > > did more than simply increment a variable or two than the problem > > might go away (because contention would be less and because the > > uncontested operations would be a bigger percentage). > > > > Going back to the original code. If it is OK to miss a few increments > > (hence non-volitile statics) then the following should be OK: > > 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. > > > - Charlie > > > > -- Scala lift off unconference, May 10th 2008, San Francisco http://scalaliftoff.com lift, the secure, simple, powerful web framework http://liftweb.net Collaborative Task Management http://much4.us --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
