my question is considering the "C" answer option.
the KandB book states:
"Some JVM's might not recognize ten distinct values. Such a JVM might
merge values from 1 to 10 down to maybe values from 1 to 5, so if you have, say, ten
threads each with a different priority, and the current application is running in a
JVM that allocates a range of only five priorities, then two or more threads might be
mapped to one priority."
what dosent mean (to me), that such a JVM is not possible, where all the 10 prio levels are mapped to 1 - such a JVM doesent use proirity at all (maybe on an older mobilephone implementation or some old ARM-JVM whatever). and in this case it is well possible thath the jvm decide at t1.start() "okay whatever i ll run t1-s run() til the and after i get back to you main()". What would mean in this case that t1 ll complete, and only after ll main()-s new mosey().run() start. And if such case could exists the answer C is no more right, isnt it?
i know it sounds little out-of-world-ish, but onestly i was really suprised to see this C answer as right, after ive read in the KandB book:
"In most JVMs, however, the scheduler does use thread priorities in one important
way: If a thread enters the runnable state, and it has a higher priority than any of
the threads in the pool and a higher priority than the currently running thread,
the lower-priority running thread usually
will be bumped back to runnable and the
highest-priority thread will be chosen to run. In other words, at any given time the
currently running thread usually
will not have a priority that is lower than any of
the threads in the pool. In most
cases, the running thread will be of equal or greater
priority than the highest priority threads in the pool. This is as close to a guarantee
about scheduling as you'll get from the JVM specification"
but what the heck, ask the question directly to the JVM: System.out.print("as close to a guarantee"=="guarantee"); ;)
what do you think?
ps.: i give it a try to answare my own question
as: as if a question ("...will probably
run most...") mentions probably considering Thread-priorities scenario, you should treat statements about jvm and priorities without "usually" "in most cases" "as close to a" words, and deal with the situation in that fashion. We could call this "explicit thread priority uncertainty erasure".
Sorry about that, just making fun, im really interested in any serious thoughts about that!!