Re: LUTask

[Mark Hamburg <mhamburg@...>]

I'm actually not worried about CPU hogs. One of the nice things about
cooperative multi-threading is that the failure mode is a CPU hog and that
is easy to detect. The failure modes for pre-emptive multithreading are much
harder to detect and debug.

What I was concerned about was the case where a thread is politely yielding
to other threads but has enough work to do that the run queue never empties
out.

I was going to worry about checking a clock or having some form of
timer-based interrupt, but it now dawns on me that a simple counter of how
many times to resume before checking for events together with some feedback
loop adjustments could deliver the needed behavior.

This, of course, depends on having a way to poll for events and get control
back immediately if none are available since the condition being handled is
one where we're prepared to process an event if there is one to process but
don't want to hold up the system if there isn't.

Another approach would be to have threads that wanted to yield time put
themselves into a separate "polite" queue. When the run queue goes empty, we
post an event to flush the "polite" queue back into the run queue if one
isn't already posted and then go polling for events. Excessive politeness
could, however, lead to excessive polling but that could again probably be
treated as a feedback problem.

Mark

on 1/30/05 3:08 PM, skaller at skaller@users.sourceforge.net wrote:

> Correct. The system does minimal context switching. If there is
> an expensive 'background' thread, it will hog the CPU. There is
> no concept of fairness.
> 
> The solution is to use pthreads as well. (pthreads = Posix threads
> = pre-emptive threads). Or even processes.
> 
> I guess any Win3.1 or Mac OS <9 will tell you that cooperative
> multi-tasking is unreliable in the sense that if even one
> 'thread' isn't polite, or just plain bugged, the whole system
> can lock up.