Re: Multitasking theory question

["AG" <ang@xtra.co.nz>]

"Darren New" <dnew@san.rr.com> wrote in message
news:3D17E1E2.AED28873@san.rr.com...
> AG wrote:
> > Well, let's take a step back and regard it as a theoretical question:
> > If you use something like "inc ax" - how do you know if it's blocking
> > or not?
>
> Um... It's not. I'm assuming the normal use of the word "blocking" here:
>
>    "To delay or sit idle while waiting for something."
>
> You know an increment instruction isn't "blocking" because you're not
> sitting idle during its execution. You know this because you read the
> instruction manual for the CPU. Similarly, you know that the MS-DOS call
to
> wait for a key from the keyboard is indeed a blocking call, because of
> similar types of documentation.

Really? If I remember correctly, even the 3.something DOS could print
while it waited for the key-press. Also, increment instruction can be
blocking
if it tries to access controlled memory (think optimistic locking for
example).

>
> But surely this isn't what you were asking?
>
> > And how does it matter? Assuming the operation completes
> > *at all*,
>
> Well, now, there's the rub, isn't it? How do you know it'll complete? If
> it's waiting for the user, and the user is waiting for the other thread to
> progress before typing, you just deadlocked.

No, you are only deadlocked if there is a circular dependance. That is -
the user must be waiting on a thread that is waiting on you. If that's the
case - tough, no amount of scheduling would help (including OS).

> Again, if you have two threads, and one calls an OS routine that loops
> indefinitely, and the OS isn't supporting threads

And suppose I call an OS routine that allows me to pull the cord from
the plug but can't handle the results? Looping indefinetely isn't what I
would
call a reasonable behaviour. It is well-defined of course, but you might
just
as well have a "full-stop" as a result of any execution.

> If the question is "where does the OS enter into it if I do all my
> scheduling myself", the answer is "when you call the OS with one thread
and
> the OS prevents all the other threads from running."

OK, I'll have to agree with that - if you really have an OS that can prevent
you
from executing arbitrary code regardless of permissions/access rightts etc
etc
that you have - then "no can do" I guess - the thing is simply broken. In
fact,
it's just not functional.

> If you don't think this is an actual
> concern, then you simply haven't tried to write multitasking programs
under
> a single-tasking OS. :-)

Will a car-engine control program written under DOS on x86 machine qualify?
:)
It probably wasn't as hard real-time as some other things around but it
certainly
was heavily multi-tasking. And I hope you wouldn't call DOS non-single
tasking.