🚀 go-pugleaf

-----BEGIN PGP SIGNED MESSAGE-----

In article <41mr50$2q2@sundog.tiac.net>,
Jim Williams  <williams@tiac.net> wrote:

>Perhaps it would better to say that you have a multitasking
>environment temporarily reduced to unitasking.  It could also be
>argued that you have a multitasking environment with a bug.
>Certainly, if maximising CPU utilization is your highest priority and
>compute bound jobs are the norm then permitting a unitasking state is
>a reasonable design decision. (I don't compute any models of
>thunderstorms myself.:)

nor do i.  but if i did, i'd want my jobs to get run as fast as
possible. :)

historically, non-preemptive systems came before preemptive systems.
non-preemptive multiprogramming was a response to the realization that
computers running simple automatic job sequencing spent a good deal of
their time waiting on I/O, during which the (incredibly expensive) CPU
could in theory be doing something else.  automatic job sequencing was
itself a response to the discovery that in manual sequencing the
system sat idle between jobs because operators are not all that fast
at loading jobs (or even noticing that the CPU has stopped running).

one way to avoid this waste of expensive resources was to speed up I/O
devices; spooling was one way this was accomplished (since disks and
tapes are faster than printers and card readers).  this helps, but
doesn't solve the problem (although it did introduce the concept of
device-independent code and logical I/O devices, found even to this
day in IBM's "virtual reader" and "virtual punch").  all of these
solutions reduce CPU lossage due to I/O delays, but they do not
eliminate them.

spooling to disk of batch jobs also led to the possibility of there
being more than one job ready to run at a time, introducing the idea
of automatic scheduling of jobs.  having multiple jobs ready to run at
once leads to the idea of letting one job run while another waits on
I/O: multiprogramming.  all of this precedes time-sharing, which did
not become commonplace until the 1970s.  multiprogramming was
developed in the days when everything was run batch, turnaround times
of a few hours were considered good, and users did not interact with
the computer directly.  

non-preemptive algorithms tend to be simpler (because they don't have
to make as many decisions).  the main difference is that a
non-preemptive scheduler will have a larger and more variable response
time than an otherwise equivalent preemptive scheduler.  utilization
remains about the same.  throughput can be higher or lower with either
algorithm, depending on the window over which throughput is computed,
the relation between average CPU burst and scheduling quantum (in the
preemptive version), and other facts.  generally, if the job pool is
mostly I/O-bound, a non-preemptive algorithm will perform a lot like
the preemptive one; however, CPU-bound jobs will cause the
non-preemptive system to have greater variability in all performance
statistics except CPU utilization.

>Are you saying I have an agenda?   :)

no, just that i'm looking at a wider picture, one that includes 40
years of computing history and systems and computational demand beyond
those of your average desktop user. :)

>BTW -- Can I have one of those machines you get to play with?

hm?  the 780 i used to manage was sold in 1986; the MicroVAX II that
replaced it was presumably sold when the company i used to work for
closed up shop in 1992 (i left in 1987).  what i have access to now is
my ami 2000 and whatever IU has.  i've also used a series of Radio
Shack trash-80s and some of the early IBM PCs (nothing with more than
an 8088, though).  the only work i've done with 386-based systems was
on a Sequent Symmetry.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMD+jLhbgfSHT/piVAQFFFAP/U7oMenruA7OzotSK0A0oyq6jyJRDWtBS
wArp4EJ2mqbK/BG/zupwC9pQNr5/R3iq1R4J8Z7Ce0lSX/ZnWUWzQJNwcYAvlsQ2
3iDBA77pMq/AEK3YOBw6APQKg8bK7LegWxGfbUULlsEjNJYr2yJskohOFf7Emmy/
RbKbgpoMi4M=
=VL9/
-----END PGP SIGNATURE-----