> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Bryce McKinlay
>
> Hi John,
>
> Thanks for your comments.
>
> John Keiser wrote:
>
> > 1. setMaxPriority(): the JavaDoc seems to indicate you can set
> max priority
> > as high as you want up to MAX_PRIORITY. Why does GCJ only make
> it smaller
> > and not larger?
>
> The JCL says that you can only use this method to lower the
> maximum priority
> of a thread group, not raise it. This makes sense to me, because
> the purpose
> of setMaxPriority() is to limit what a thread can do with
> setPriority(). If a
> thread could raise its own maximum priority (ie using
> currentThread.getThreadGroup().setMaxPriority()) then there
> wouldn't really be
> much point!
>
OK, makes sense.
> > 2. activeCount(): It seems activeCount() should only count live threads,
> > right? Why count all threads?
>
> Because as far as I can tell, and despite what the JCL suggests, "active
> thread" just means "any thread that is in the threadgroup", regardless of
> whether that thread has been started yet. When a thread finishes, it will
> automatically removes itself from its group and thus be consided inactive.
>
I think it must be a bug in Sun's Java that non-started threads are
considered "active."
It was reported as such on the JDC this month:
http://developer.java.sun.com/developer/bugParade/bugs/4089701.html
But no conclusion from Sun has yet been reached.
> > 3. activeGroupCount(): Similar question here--though I can see how
> > Classpath's is probably wrong as well, counting all threads
> instead of all
> > active groups.
>
> I've assumed that "Active ThreadGroup" means "any threadgroup that isn't
> destroyed" because its simpler and consistent with the assumption above.
>
True, given the assumption above this makes sense.
> > 4. synchronized: I noticed a lot of synchronized keywords were
> removed from
> > one to the other. Do y'all feel they were unnecessary for
> thread safety?
> > (Seems like if anything should be threadsafe, it's ThreadGroup
> and Thread.)
>
> Oops. Somehow I dropped some synchronized flags. Certainly they
> should be at
> least synchronized to the extent specified in the JCL. I guess things like
> destroy() should be synchronized wrt addThread(). Will fix.
>
Remember also that even if the JCL does not have a method "synchronized" it
could have a synchronized block internally. I found a few such probable
places when first going through all of this.
> I've attached a couple of test cases for your points 1,2,3 above.
> These tests
> run identically on JDK1.1.8, JDK1.2.2, and libgcj on Linux.
>
Muave might like these :) Send them to their list at least. Given that
there's still dispute over their correctness, it might be best to wait, but
this would give them a start anyway.
--John
