Re: Multitasking on 8-bit Apple

sarkeizen wrote:
On Aug 14, 6:46 am, winston19842005 <bjjlya...@xxxxxxxxxxxxxxxxxxx>
wrote:
On 8/14/09 2:03 AM, in article
c13f45a2-5e61-4cbe-a2a2-08cc3be7c...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx,

"mmphosis" <markwst...@xxxxxxxxx> wrote:
The second requirement is, of course, a source of interrupts to do
time-slicing. For without interrupts, one is limited to co-operative
multitasking such as that used on the classic Mac OS.
What is so bad about co-operative multitasking?
You really don't know? Task-switching occurs only when the program currently
executing relinquishes control - instead of having a way to interrupt a
program no matter what it is currently doing.

Is this bad? Many think so. I remember my old Mac, and it ran pretty damn
good - although many appear to have horrible memories of the old, now-called
"Classic OS".

The downside was if you had a program misbehave, it often took down the
entire OS. Funny this often happens in Windows XP as well, and it is NOT
co-operative multitasking. And it has happened a few times to me in OS X.

Another way of looking at it is that in co-operative all code is
executing at the same privlilege level. So no code can exert the
right to execute over another. The pros of ths approach is that it is
easy to implement just sprinkle a "release" call in you main loop and
your libs and you're done. It also can be desgned so that it incurs
very little overhead. That is you can release contol when the
registers don't contain anything meaningful. The cons have been
already detailed by others.

I would have said that all programs are running at the *highest*
priority, in the sense that any program can starve all others.

That's where the "cooperation" comes in. ;-)

By contrast preemtive multitasking often requires hardware and a task
switch is often costly especially on mdern CPUs with a large register
set. The pros are that it ensures "fair" schedualng. However what
that entails is often domain specific I.e. A server and a workstation
have different requirements.

The 6502 has a serious problem with state saving as well--its stack
and page zero are its "registers". Bank switching is a fast solution,
but it tends to be a pretty blunt instrument, in the sense that more
than you might like is switched by a single switch.

(BTW, register files can be bank-switched, too, often with relatively
little implementation overhead--consider the Z80.)

As others have noted this certianly doesn't stop a high priviledge
task from locking your machine in a similar way ( I tend to curse XP/
Vista networking code a lot for this)

A priority scheduler introduces complexities of its own, "priority
inversion" on mutual exclusion being one of the pitfalls.

One other approach is if you can assume that your entire os is running
in an interpreted language you can essentially get all of this "for
free" since the interpreter essentially becomes the schedualer. It
would also allow you more fine grained memory management.

A multiprogrammed Applesoft environment is fun to consider... ;-)

-michael

NadaNet 3.0 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
.

Quantcast