🚀 go-pugleaf

In article <43auuk$41@starfruit.csd.sgi.com>,
Kevin Brown <kcbrown@starfruit.csd.sgi.com> wrote:
>In article <nevin-0709950221230001@mac-nevin.cs.arizona.edu>,
>Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>>I have a little secret for you:  the only difference between CMT and PMT
>>is how tasks get swapped; ie, the whether scheduling is under application
>>control or OS control.  Neither solution is perfect.  CMT apps have to
>>guess about what the rest of the system is doing; PMT OSes have to guess
>>about what all the apps are doing.  Some PMT schedulers, such as the one
>>in Copland, will be better at doing this, since the apps will cooperate by
>>telling the OS exactly what kind of task it is (UI, CPU-bound, etc.);
>>schedulers rarely get this right using heuristics alone (such as the Unix
>>scheduler).
>
>However, PMT at least has a *chance* of getting it right adaptively,
>because the OS can track the activities of the processes.  CMT has no
>chance at this.  CMT programs must *literally* guess blindly about
>what to do because the OS provides them no information about what the
>other processes are doing.  Therefore, PMT will be better than CMT in
>all but the most pathological of cases.

One thing that's "good" about PMT that's often overlooked is that it
doesn't allow the programmer to make assumptions about whether real
or apparent concurrency is going on. You have to use synchronization
mechanisms which scale well to multi-processors.  The way cooperative
multitasking is done on the Mac is particulary bad, because it is
based on ad-hoc methods.

For example, Mac applications can obtain memory blocks from something known
as the global heap---free memory that belongs to the system. When a
program exits, the global heap blocks associated with it are released.
So far so good, right? Here is where the stupidity comes in: the system
re-arranges the allocated blocks in order to defragment the free space,
by physically pushing their contents around memory. If you store pointer
references to data within a block that has been moved, they will no longer
be valid. The reason this scheme can work is because of the "cooperative"
multitasking. You see, as long as you don't give up the CPU, memory will
not be moved on you. After your program returns from an explicit "yield"
call, it has to take steps to ensure that all accesses to global blocks
go to the right places, by dereferencing the right handles. Not only
is the CPU not virtualized, but neither is storage. 

The Mac system programmers should have read the volumes of The Art of
Computer Programming by Donald Knuth, in particular the sections on heap
management where it is argued that it's better to coalesce adjacent free
blocks into larger blocks than to try to do garbage collection.  I
suspect that the programmers probably had experience implementing
BASIC interpreters (kind of like Billy Gates), and applied similar
strategies to OS programming. ("Let's do garbage collection like old
Applesoft BASIC did on strings!")
-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.
Microsoft users: crash test dummies?