Date: Mon, 2 Feb 1998 10:03:25 -0600 (CST) From: Damon Permezel <dap@damon.com> To: nate@mt.sri.com (Nate Williams) Cc: jb@cimlogic.com.au, nate@mt.sri.com, SSANKARA.IN.oracle.com.ofcmail@in.oracle.com, freebsd-java@FreeBSD.ORG, java-port@mt.sri.com (Java Port) Subject: Re: TimeSlicing in JVM Message-ID: <199802021603.KAA06305@damon.com> In-Reply-To: <199802020636.XAA26813@mt.sri.com> from Nate Williams at "Feb 1, 98 11:36:21 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
On a similar thread, what do folks feel about the implementation of
yield? With non-preemptive threads, yield does:
(from sysThreadYield()):
if (runnable_queue && runnable_queue->priority == self->priority) {
... yields to threads only of the same priority.
This means I cannot write a CPU hog function, run it in a low priority
thread, and call yield() periodicially, expecting the higher pri runnables
to get some CPU.
This forces me to run my CPU hog at "normal" priority, and means that
the async garbage collector thread will never run, unless I also arrange to
call it from the CPU hog function.
I would have preferred to have the hog run at THREAD_MIN (or whatever it was
called) which is where the async GC runs, and have it be able to yield
the CPU to the user interface threads, and other threads, as well as the GC.
(I know that this doesn't really solve the GC issue.)
I haven't experimented with changing it to:
if (runnable_queue && runnable_queue->priority >= self->priority) {
as it is often easier (and "better") to work around these issues in my app,
but I believe such a change is warranted.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802021603.KAA06305>