🚀 go-pugleaf

In article <kevinbDMFzyt.1q3@netcom.com>, kevin@frobozz.sccsi.com (Kevin
Brown) wrote:

> But in a PMT system, the idea is that you don't *have* to know the
> state of the system.

Not true.  They way PMT systems get around this is by creating a bunch
more system calls, since that is the easiest way of guaranteeing
atomicity.  If they forgot to create a call that you need, you're out of
luck.

My canonical example of this is mkdir(2).  You cannot robustly implement
mkdir as a setuid root program, even though all it does is create one file
and edit another.  Why?  You have to make sure that there is no duplicate
directory name in the parent and create that entry (ie, edit the parent
directory) all in one atomic action, as far as the outside world is
concerned.

I'm willing to make a good-faith (no technicalities) $20 wager that you
cannot implement mkdir as a setuid root program, without calling mkdir(1)
(or something similar to guarantee atomicity) that cannot be broken (leave
the directory structure in an inconsistent state) by a user-level program
(possibly running as root), such as kill -9, mkdir, rmdir, or one of my
own design, possibly based on the source code for your mkdir.  Any takers?
:-)

Instead, you write your program under the
> It's *all* about tradeoffs, but the question is what the tradeoffs are
> and where they are most appropriate.  CMT is better only under *very*
> strict circumstances.  PMT is going to be better under all other
> circumstances, including most RT and interactive environments.

Unfortunately, many of those environments, don't treat interactive human
processes as special.  What I want out of X for instance, across the whole
machine, is that interactive processes in the foreground get the most
priority, those in the background get less, and the batch stuff without
real time requirements the least.  I'll be able to do it in Copland,
because a process tells the scheduler what kind of task it is (using soft
priorities, so the scheduler can decide what to do, but you can give it
hard priorities if you really need to); I see no easy way of doing this
with the Unix scheduler.

Scheduling is a function of both what the app is trying to do (local
scheduling) and the load on the system (global scheduling).  CMT errs in
favor of the app knowing what it is doing, since it is possible for the
app to figure out the load on the rest of the system.  Unix PMT errs on
the side of the system and "fair" scheduling, but it has no way to
determine what the needs of the app actually are (past performance is a
very lousy indicator, especially where humans are concerned).  Copland,
with its soft priorities, is a great compromise, since it takes into
account both the needs of the system and the needs of the application.
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799