🚀 go-pugleaf

c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:

>In article <fyock-2308950935260001@144.212.1.78>,
>Lee Fyock <fyock@mathworks.com> wrote:
> >In article <41d4a5INNgj0@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
> >(Kazimir Kylheku) wrote:
> >
> >> Multitasking means that you at least
> >> simulate concurrency using time slicing.
>
> >Yes, but how you time-slice depends on the implementation of "multitasking".

>And if you don't time-slice you don't have multitasking. You can call it
>"cooperative" to save face, and provide your MacOS or Win 3.x userbase
>with a buzzword.

If you don't time-slice, you don't have multitasking?  That's silly.

Although, this isn't terribly relevant for general purpose operating
systems, there are fully preemptive multitasking systems that don't 
use time-slicing at all.  Many real-time kernels, for example.

Hell, you could have a fully preemptive kernel that doesn't do any time
slicing managing different schedulers whether they be preemptive, 
non-preemptive, time-slicing or even just a single task.  Sheesh.

There are situations where a non-preemptive multitasking system works
_considerably_ better than a preemptive system would.

Personally, I'd never use anything but a preemptive time-slicing scheme
for a general purpose operating system, but to deny that other schemes
don't exist or are not useful at times is just plain silly.

> >> It means that other tasks are
> >> truly running whether or not my program yields.
> >
> >That's "pre-emptive" "multitasking".

>Only kind there is.

See above.

> >> It means that I
> >> can send signals and messages to that program from another program.
> >
> >No, that's "inter-process communication", which has little or nothing to
> >do with multitasking.

>It has everything to do with multi-tasking. You can't send a message
>or signal to a process that is hogging the CPU. You can't have
>any sort of asynchronous notification of incoming messages.

That's like saying, "You can't send a message or signal to a process when 
my process is not running."  OF COURSE NOT.  It's just like that with a 
time-slicing preemptive scheduler.

Sending messages and signals from one process to another process doesn't
really have very much to do with the scheduling mechanism.

No asynchronous notification of incoming messages?  Interrupts.  Heard of
those?  Nifty things.  Useful too.  Funny how that works.  Sheesh.

Sure when a non-preemptive scheduler, when a high priority process receives
a message, it won't start executing >NOW<, it has to wait until the 
currently running process yields the processor, but that doesn't mean that
processes can't send and receive signals and messages.  
-- 
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc