Seeing as how grad. students seem to be the only one's awake at this hour
and reading/posting to the list, I can get away with assuming I understand
everything that is going on his code.
What he did was write his own scheduler, (the MAXPRI thread). It probably
sleeps for fixed period of time, acting as the clock tick. On the pseudo
clock tick, it switches in the next thread, by elevating its priority or
resuming it. (All of the work threads are assumed to be computationally
bound. I/O bound threads don't have this problem.)
Perhaps, the Java folks felt it was better that users customize their
scheduling rather than have everyone pay the overhead for fair share
scheduling. (Questionably little overhead. :( )
-d
e-mail: [EMAIL PROTECTED], the rest: http://www.csrd.uiuc.edu/~dcraig
On Wed, 24 Feb 1999, Moses DeJong wrote:
> On Wed, 24 Feb 1999, Chris Raser wrote:
>
> >
> > On Wed, 24 Feb 1999, David Craig wrote:
> > > Java doesn't define how threads of the same priority share cpu time In
> > > some VM implementations the sharing is fair. On others, such as the port
> > > you're probably using, one thread preempts the other indefinitely.
> > >
> > > Congrats on an elegant workaround. :)
> > >
> > Actually, it's not my own invention, and I'm sure that others have
> > done something similar. All I did was create a thread of "MAX_PRIORITY"
> > that just goes right to sleep. It preempts everything else, then gives
> > the little guys a chance to do their thing. (and I write a minimum of
> > extra code to keep everything moving) Maybe "honorable hack" is a better
> > term than "elegant". <smile>
> >
> > Thanks for the info- my java-idealism was getting just a little
> > out of controll there for a second... ;)
> >
> > -chris
>
>
> I do not mean to rip on your code or anything, but if you require a
> big hack like that then something must be wrong with the design of
> the program. Please do not take that the wrong way. Why exactly do
> your threads starve each other? Are they polling or something? Most
> of the time a polling process can be replaced by a signal based
> process and you will end up saving a lot of wasted CPU time.
> Just a thought.
>
> Mo DeJong
> dejong at cs.umn.edu
>
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
