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.
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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
