[3728] in java-interest
Re: Setting a thread's priority...
daemon@ATHENA.MIT.EDU (David Strauss)
Thu Nov 23 15:57:28 1995
Date: Thu, 23 Nov 1995 14:21:36 -0500 (EST)
To: kanderso@ics.uci.eduo.java-interest@java.sun.com
From: dstrauss@panix.com (David Strauss)
In article <kanderso-2011952305050001@128.200.199.91>, kanderso@ics.uci.edu
says...
>
>Hi,
>
>Why is it that you can't set a thread's priority until after you start() it?
>
>Thanks in advance,
>
>Ken
>
>--
>Ken Anderson
>Graduate Student
>University of California, Irvine
Where does it say this? There's a demo applet that goes with the
Java Programmer's Guide called RaceApplet that implements a "race"
between two threads. It has a parameter that allows you to set the
priorities equal or non-equal. This applet does the setPriority calls
BEFORE it calls start, so of you are correct the demo has a bug.
Interestingly enough, when I tried to run it (in Win95) equal or
unequal priorites made no difference -- when the priorities were
set unequal, the higher priority process did not win any more often.
It looked to me like round-robin time-slicing was being implemented
with absolutely no regard for the set priorities.
When I saw your post I put the setPriority calls after the
start calls and nothing changed. So I have two questions -- 1) where does
it say that setPriority must be called after start? and 2) why
do I not get the expected behavior when I run the RaceApplet demo?
Does it have to do with the way thread scheduling is implemented in Windows
95?
--
------------------------------------------------
David Strauss
E-mail: dstrauss@popserver.panix.com
dstrauss@lehman.com
-------------------------------------------------
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
