🚀 go-pugleaf

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

In article <41diciINNj1j@keats.ugrad.cs.ubc.ca>,
Kazimir Kylheku <c2a192@ugrad.cs.ubc.ca> wrote:

>>preemptive multitasking is _less_ efficient than nonpreemptive
>>multitasking, because of preemption overhead.  many supercomputers run
>
>The overhead is insignificant. One hundred clock ticks per second
>are nothing to a modern CPU. Even the Commodore 64 had a 60hz clock
>tick for updating the clock and hooking in user interrupt routines.
>You don't know what you are talking about.

time spent servicing _any_ interrupt is time that can't be used for
computation.  it may not seem like much, but in a time-critical
(i.e. real time) application, it can be.

>The cost of having to place yield calls in "cooperative" code
>is greater.

you don't _have_ to put in yield calls.  on batch-only systems
(precious few of those left, eh) jobs need not yield except when
blocked.  on a batch system the goal of the system owner is to
maximize CPU utilization because they get paid by the utilized cycle.
cycles used by system software aren't paid for by clients.

i used to work for a company that occasionally contracted out to
Boeing Computing Services.  as i recall, their Y-MP used a limited
preemption scheduler; preemption only occurred if a higher priority
job entered the queue.  the queue itself was managed by the front-end
processor.  jobs could be loaded without halting the main processor.

>The loss of scalability is also pitiful. How do you scale cooperative
>threads to a symmetric multi-processor, when they are designed with
>the tacit understanding that no concurrent execution happens as long
>as you don't yield the CPU?

you're off on a tangent here.  please remember that basically, i agree
with you. :)

>>however, maximizing CPU utilization is not generally the goal of most
>>systems; balancing CPU utilization with user responsiveness is a more
>>common goal.
>
>The user responsiveness of a "cooperative" system with a runaway
>"background process" is simply astounding.

i'm well aware of that.  IMO, cooperative multitasking is only
suitable for batch and realtime systems; CMT is acceptable in batch
systems because minimizing wait times is not a primary design goal,
and it's acceptable in realtime systems because in a realtime system
it is (a) assumed that the processes will be completely aware of the
environment and/or need to be able to assure maintained control of the
CPU in order to service events promptly.

>>i guess this all goes to prove that "those who do not learn from
>>history are doomed to repeat it."  all of this nonsense has been done
>>before, just on different computers by different companies.
>
>You are forgetting that the cooperative nonsense was also done before,
>and is repeated by fools who do not learn from even earlier history.

i'm not forgetting anything.  you're not reading what i'm writing; i
am _not_ advocating the use of cooperative multitasking in interactive
systems; i've said several times that i think cooperative multitasking
is not well-suited to an interactive environment.  what i am saying is
that one has to select one's scheduling policy based on the environment
in which it will be used.  there is no one ideal scheduling policy.

>Mac programmers didn't learn from the history of the IBM 360
>architecture, which--- almost exactly like the 68000---had 32 bit
>address registers, but with only 24 external address lines (the 68K has
>the least significant line decoded into an data strobes).  Some
>programmers used the "extra" bits as pointer tags, making their code
>non-portable to full, 32-bit implementations of the architecture.
>Twenty years later, some Mac programmers were guilty of doing the same
>thing.

richard stallman did the same thing with emacs, making ports to 64 bit
architectures as well as to 32 bit architectures where the upper 8 bits
were non-zero in the heap difficult.

steven bourne's memory management scheme for bourne shell was to just
write the memory and, if you get a sigsegv, sbrk some more memory and
restart.  works fine on a PDP-11.  not so good on other architectures.

history is full of cheap tricks like this that break if you change
anything.

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

iQCVAwUBMDzyhBbgfSHT/piVAQFhMQP/YfOo3qQzHPxaSOc5AV0jA1J+1dWLWVaQ
v4Mr+aBreaLjsHxMRvSZlcWMrRzovz3izUyiMBCXI9nwDYTJW5/nOnpP6YTyeQ2r
LsNJEap86xEaRd6KH9JFETiFLgDhNhADO/9uxknPx93rC3Jr0C8cDUwDuCT1QiW5
xSe8xmY9EVY=
=riUT
-----END PGP SIGNATURE-----