2009/11/3 Stuart McCulloch <[email protected]> > 2009/11/2 Brent <[email protected]> > >> >> But why does the JVM have to know my intent... It knows that I >> started a thread and it knows that it has some priority. So why can't >> it just stick all of the threads that were started for a particular >> priority on a queue and then iterate through that queue. It might be >> easier said then done, but that's what I don't understand. >> >> Example: >> >> If you have 3 threads with same priority... >> >> Thread 1 (default priority 5) >> Thread 2 (default priority 5) >> Thread 3 (default priority 5) >> >> Let's pretend that each thread executes 2 loops. >> >> Execute Thread 1 >> Execute Thread 2 >> Execute Thread 3 >> Execute Thread 1 >> Execute Thread 2 >> Execute Thread 3 >> >> If the threads have different priorities then this wouldn't work, but >> assuming that they have the same priority why doesn't the JVM do >> this? Can you dumb it down for me more? >> > > does this comparison help? > > updates to fields in Java are not specified to be atomic > => use synchronization to guarantee atomic updates > > scheduling order of threads on Java locks is not defined > => use "fair" locking to guarantee scheduling fairness > > ie. you should not rely on behavior that is not specified. > I don't say this is easy - avoiding this is a hard problem, > especially when there's few alternative implementations > that you can run tests on > > I've seen a lot of customer code that relied on unspec'd > behavior all over the JDK - including one who was using > mutable keys in a hash map (which is not good at all!) > and expected it to work a very specific way :( > > We experienced this issue running Weblogic 9.2 container and the >> thread scheduling isn't even available to us since it's a EE container >> and you're not suppose to manage threads. Ultimately, what you're >> telling me is that weblogic has a bug and that they should have used >> java.util.concurrent. >> > > I haven't seen your app code, so I can't really comment. > > If you're pushing the container provided threads through > basic (non-fair) locks then you might need to switch to > use fair locking - if the container is the only one doing > the locking then they probably have a bug. >
also I should say that scheduling is a hard problem, and policies that guarantee no starvation often have downsides in other areas (eg. response/throughput) http://en.wikipedia.org/wiki/Scheduling_%28computing%29#Overview otherwise why would the HotSpot 1.5 JVM suddenly change their lock ordering - it must have had benefits elsewhere, I doubt they did it just to annoy people! > On Nov 2, 9:53 am, Phil <[email protected]> wrote: >> > I think you're missing the point. The JVM can't know your intent when >> > you started your threads and cannot know that the right thing to do is >> > to 'level' resource usage across your threads. If you need your >> > threads to receive a more equal share of resources then this needs to >> > be expressed in your design. Hence the suggestion to use fair locks to >> > more precisely influence the scheduler. >> > >> > Even the thread priority is not a hard and fast guarantee, just an >> > indication (or to quote a pirate: the code is more what you'd call >> > "guidelines" than actual rules). If you read a good Java certification >> > textbook it will tell you threads must have priorities, and that the >> > priority can be between 1 and 10, but it does not dictate what the JVM >> > should do about these different priorities. In general, scheduling >> > algorithms are left to the implementor, about the only thing you can >> > be certain of is that 1 is viewed as the lowest priority, 10 as the >> > highest and 5 as the default. Beyond that, all bets are off. >> > >> > Phil. >> > >> > On Nov 2, 2:32 pm, Brent <[email protected]> wrote: >> > >> > >> > >> > > How does that look ok to you? Threads 0 and 1 only executed 23 times >> > > while the other threads executed 45/46 times. How can that ever be a >> > > good thing? >> >> >> > > > -- > Cheers, Stuart > -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The 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 -~----------~----~----~----~------~----~------~--~---
