In message <[EMAIL PROTECTED]>, Paul Kinnucan write
s:
: Eric, I am a little confused. Are you saying that my thread priority "fix"
: in beta10 is an improvement? If so, that is very interesting. I believer
: there other debugger threads that JDEbug sets to max priority (actually
: MAX_PRIORITY-1). I've never understood why the code, which was written by a
: Sun summer intern, was setting the priority of these threads. However,
: since the intern was working as a member of the JPDA team, I assumed he had
: access to inside information so I was reluctant to touch his code in this
: area. Recently, however, I have been reading Holub's "Taming Java Threads"
: and found his discussion of how thread scheduling differs drastically from
: platform to platform enlightening and horrifying. Holub's advice is
: basically just not to monkey with thread prioirty since you can't set
: priorities in a platform-independent way. So I'm inclined to comment out
: all the set-priority calls in the JDEbug code.
Yes, the beta10 fix yielded a working debugger in both emacsen. There
were no changes to code or to the number of ambient processes between
the upgrade, and I repeated the exercise with a downgrade (didn't work)
and a re-upgrade (worked). But also keep in mind the importance of
upgrading the VM itself from 1.3 => 1.3.1.
In my experience Holub is exactly right. In VMs (linux) that implement
threading as processes, the scheduler in the kernel has an opportunity
(indeed, an obligation) to control "threads" in a way that just doesn't
happen when threading is implemented within a single process.
I was curious, so I wrote a little priority test in which I start two
threads, one with MAX_PRIORITY and the other with MIN_PRIORITY.
Each thread has an instance of a Runnable whose run method looks like
this:
long runcount = 0L;
public void run() {
try {
while (true) {
System.out.println(Thread.currentThread().toString() + ":" +
runcount++);
} // end of while (true)
} catch (Exception e) {
e.printStackTrace();
} // end of try-catch
}
Since these runnables are just competing for CPU time (and System.out, of
course), you'd expect the one that belongs to the Thread with MAX_PRIORITY
to eventually end up with a much higher runcount.
Curiously, my results are exactly the opposite: if left to run ~10,000
times, the MIN_PRIORITY thread ends up about 1,000 iterations ahead.
I ran the test a few times, for different durations, and MIN_PRIORITY
always got more cycles.
I conclude from this (completely unscientific) test that you and Holub
are exactly right - setting thread priorities isn't worth the trouble,
because of the inherent OS dependencies in scheduling.
As to trusting the inside information of Sun's summer intern - well....
The JDK has quite a few classes that were probably written by well
meaning, but poorly mentored summer interns. The Observable/Observer
classes are a disaster because of the requirement that you sublass
Observable to use them (observable should've been an interface and Sun
should've provided an "observable support" class to which implementors
could delegate, a la property change support). java.text.BreakIterator
is terrible because it cannot be extended to introduce more intelligent
segmentation rules, which is why IBM had to rewrite it. Making Stack
a subclass of Vector is pretty awful too, since you end up with a data
structure that can be altered in all kinds of un-stack-like ways if
people aren't paying attention.
At any rate, it's very easy to criticize someone else with the benefit
of 20/20 hindsight (and it's fun too, as Homer Simpson once said, ha ha),
but suffice it to say that I'm not exactly shocked that a javasoft insider
would flub some multithreading code - it's still darn hard to get right,
even if you're spending a summer in the Silly Valley.
Eric
