On 18/03/2005, at 12:36 PM, Paul Koning wrote:
>>>> "Huw" == Huw Davies <huw.davies at
kerberos.davies.net.au> writes:
>>>
Huw> Anyone who's used a Macintosh before OS-X might want to disagree
Huw> here.
Depends on what you're doing.
If you want to run large workstation applications, then you want a
real Unix-style OS.
The original question was for a very small multitasking system, which
to me sounded more like an embedded/RTOS type of application. That's
where the cooperative style often works better.
I suspect a lot depends on how much control over the total environment
you have.
For a small embedded/RTOS you probably have (or at least should have)
total
control. If you don't you're depending on the writer of one (or more)
of the
processes "doing the right thing". Now probably they will try to do
this, but
any subtle bug may lead to one of the processes failing to relinquish
the CPU
and then "bad things happen (TM)" - this was the typical Mac experience.
Of course, having said that, Macs worked remarkably well for many years.
One benefit of cooperative, rather than
preemptive, scheduling is that
the scheduling properties and liveness properties of the various tasks
are very obvious. If reliability demands that everything gets a slice
of time, then cooperative multitasking, without priority, is a great
way to get the job done.
Are the risks in preemptive scheduling just ones of complexity? I guess
that it is much harder to "prove" that this type of scheduler is going
to to the right thing at the right time. I know that,
for example, the scheduler for VMS has gone from a couple of pages of
assembler
to something like 75 pages of BLISS!
Huw Davies | e-mail: Huw.Davies
at kerberos.davies.net.au
Melbourne | "If soccer was meant to be played in the
Australia | air, the sky would be painted green"
The advantage of a preemptive scheduler is that a dead process will not
block a task swich. This problem, as observed by other list members,
should not occure in a properly designed system. But what isystem is
properly designed after you have more than one developer working on it?
Jim Davis,