Path: utzoo!attcan!uunet!willett!dwp
From: dwp@willett.UUCP (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Experimental Ideas
Message-ID: <1436.UUL1.3#5129@willett.UUCP>
Date: 31 Jul 90 03:32:12 GMT
References: <1433.UUL1.3#5129@willett.UUCP>
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 38

In <1433.UUL1.3#5129@willett.UUCP>, F.SERGEANT [Frank] writes:
> 
>  > And round-robin scheduling is a key.
>    Robert, I assume you mean that the task accessing the block doesn't  issue
> a PAUSE until it is safe to do so.  I like (& have always liked)  the round-
> robin, co-operative multi-tasking approach, although I  haven't done much with
> it.  Once in F83 I set up a buffered  serial-input as a separate task.  It
> worked very nicely.  I've thought  one of CM's ideas on multi-tasking was that
> instead of having a single  task requiring complicated co-ordination, you have
> a number of simple  tasks, each of which can be tested alone.  So, in (this)
> theory,  multi-tasking should make the debugging easier, but it sounds like
> you  have experience to the contrary.
This is a point which seems to go back and Forth.  One looks at, say,
Windows with its wimpy cooperative multitasking (one run-away process
and wham, U R SCREWED) and says:  YUCKO!  Preemptive process swaps are
much nicer, you don't have to worry about "relinquishing in enough
places".  Especially much much nicer where processes/tasks have their
own separate address spaces so that they don't accidently interfere with
each other or have to worry about preemption in bad places (external
data consistency is not the point here).  Of course, lightweight
processes (threads as they are sometimes called) also have their uses.
Either round-robin-cooperative or preemptive.  Sharing address space is
occasionally useful.   Esp. if the OS is thread-aware, then you can do
non-blocking-I/O with parallel threads (even if the kernel doesn't
"really" support non-blocking-I/O) and other such interesting stuff.
I suspect that the heavy-weight/light-weight debate will never be
resolved simply because there are different needs that aren't easily
subsumable under one or the other.  I'm not suprised that Forth takes
the lightweight approach, since that is easier and requires less
hardware support too.  One might "fake" preemptive by modifying NEXT,
and adding primitives for critical sections.  I'm not sure what the
analogy for subroutine-threaded code is, perhaps changes to : ?

-Doug

---
Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp   [in a pinch: dwp@vega.fac.cs.cmu.edu]