The good news is that the synchronized keyword is getting really cheap so code that gets distorted trying to avoid synchronized should just code it up simply. Then there's the 1.5 concurrency support, which is fantastic. Brian Goetz has talked about an arms race between the VM guys and the concurrency guys to try and shave nanoseconds off this stuff.
The pain comes when a chunk of code enters a synchronized block and doesn't immediately return, when it calls other objects that may have thier own synchronized blocks and you can hit a deadlock that way all too easily. On Nov 19, 2007 1:14 AM, Christian Edward Gruber <[EMAIL PROTECTED]> wrote: > I've usually found my race conditions, or stupid multi-threading > mistakes with 2 processors just fine. I'm just trying to wrack my > brain to find one that would be solved with 3+ that wouldn't be found > with 2. Hmmm... > > Christian. > > > > On 19-Nov-07, at 12:49 AM, Howard Lewis Ship wrote: > > > It's not deterministic at all and that's the scary part. Another > > option would be to create a virtual multi-core computer that exists to > > force unlikely but valid race conditions, to ensure that they are > > handled properly. But I'm anything but an academic. > > > > On Nov 18, 2007 12:39 PM, Christian Edward Gruber > > <[EMAIL PROTECTED]> wrote: > >> Wouldn't you get proper multiprocessing behaviour from a dual-core > >> processor, since the choice of processor that is accessing a given > >> thread at any point isn't deterministic, nor is thread execution > >> order? Or would you just find the issues faster on 1000 processors. > >> > >> christian. > >> > >> On 18-Nov-07, at 1:47 PM, Howard Lewis Ship wrote: > >> > >>> That would be an interesting research project, a JVM that runs > >>> inside > >>> a virtual hyper-multicore system. That is, a simulation of a, say, > >>> 1000 core workstation, used to flesh out synchronization problems > >>> that > >>> won't manifest inside single or dual-core CPUs. > >>> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > -- > > Howard M. Lewis Ship > > Partner and Senior Architect at Feature50 > > > > Creator Apache Tapestry and Apache HiveMind > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
