Subject: Re: suspend() thougths

From: Mike O'Brien <[email-masked]>
Date: Tue, 21 Sep 1993 12:49:00 -0700

I've been thinking about it, and it's occurred to me that
I may be the only person on this list who's seen this tick problem
before, in another context, so I thought I'd share it.

	Fifteen years ago, the PLATO computer-based education
system at the U. of Illinois came across this problem.  This
system, architecturally, was very similar to LambdaMOO.  It had
a threaded-code interpreted language, TUTOR, executed in a unique
environment.  Response analysis was handled by user-written code
which, at that time, had to complete within a timeslice (equivalent
to the current "tick" limit).  This was too restrictive, so after
some time, a new command was added to the language which was
functionally equivalent to "suspend_if_needed()".  This took
the immediate pressure off.

	So far, the parallels are exact, I'd say.

	The upshot was that, eventually, the TUTOR interpreter
was rewritten to be able to save full context across a timeslice
and the restriction was removed entirely.  The "suspend_if_needed()"
primitive was converted to a no-op for the sake of backward
compatibility.

        The one difference from the MOO environment was that
users had a non-interceptable "bail-out" keypress available to
them if they wound up in an infinite loop.  The equivalent would
be "terminate all tasks and go 'home'".  Since student records
carried equivalent baggage to a character in terms of
permanently-saved state, this implied all the dangers that one
could foresee if this were done in MOO.  However, the benefits so
outweight the drawback, which could in any event be provided for,
that no one ever looked back.  TUTOR users today would look at
you funny if you told them about the bad old days of
"suspend_if_needed()".

	Problems of "lag" and fairness were handled by implementing
a real scheduler which penalized for excessive CPU usage.

Mike O'Brien

---

From: Arthur Chandler <[email-masked]>
Date: Tue, 21 Sep 1993 14:12:20 -0700

" Problems of "lag" and fairness were handled by implementing
a real scheduler which penalized for excessive CPU usage.

                        Mike O'Brien"

   I'd like to know more about this plan. Could or should MOOs
monitor CPU usage and have "quotas" based on login time or resources
used? Also,on several MOOs I see listings of people who have been idle for
hours, or even days. What kind of resources do these folks consume?

---

From: [email-masked]
Date: Tue, 21 Sep 1993 15:38:23 -0700

yduJ remarks:

>>What the scheduler does not do is preemptive scheduling; it waits for
>>a task to yield control (the ticks and seconds limits aren't exactly
>>"yielding control", but they act pretty much the same).

Yes, this is precisely the change that was made on PLATO: from
voluntary, Smalltalk-style "yield" scheduling to preemptive scheduling.
It was a big help.

Mike O'Brien

---

From: Judy Anderson <[email-masked]>
Date: Tue, 21 Sep 1993 15:31:11 -0700

The MOO scheduler already *does* penalize for excessive CPU use.  If
you use lots of CPU, it puts you off until some more people have used
that much CPU.  I don't remember exactly; Pavel described the
algorithm once to me after I accused him of doing this sort of thing.
Not only that: if your task runs out of seconds, usually it has used
*more* than its alloted number of seconds, and you don't just wait for
the standard max seconds, you wait for the whole amount you *used*
(even though you didn't get to see the results of this use!).  This
frustrates me when there are runaway tasks and I'm hunting them down;
one mistyped call to ;queued_tasks() from the wizard character and
it's dead in the water for 10-15 *minutes*.

Judy Anderson yclept yduJ   [email-masked]  'yduJ' rhymes with 'fudge'
    [ LambdaMOO is lambda.parc.xerox.com 8888 / 13.2.116.36 8888 ]
       Join the League for Programming Freedom, [email-masked]

---

From: [email-masked]
Date: Tue, 21 Sep 1993 16:45:05 -0700

> voluntary, Smalltalk-style "yield" scheduling to preemptive scheduling.

Yah, but it does not solve the problem of already existing verbs which rely on
the fact that they will *>NOT<* be preempted until they explicitly say they
should be.

Refer to the pathetic thread I'm ashamed to have started here a short while
ago to see what happens when you try to remove this quality and make
preemptions happen implicitly.

MOO is pretty firmly rooted in this "yield" scheduling style you refer to. 
Even if you put in implicit preemption and rewrote the Core database to take
it into account, I doubt you'd have an easy time herding neophyte programmers
into using it.  Personally, I have a hard enough time trying to explain fork().

I'm shutting up now!  Really!

--joe

---

From: [email-masked]
Date: Thu, 23 Sep 1993 12:32:43 -0700

>>the fact that they will *>NOT<* be preempted until they explicitly say they

Well, for what it's worth, PLATO "solved" this problem by leaving in their
equivalent of "suspend()" (note: not "suspend_if_needed()").  This would
guarantee you a full timeslice when it returned, for critical code sections.

They did this because it was easy.  Actually what's needed are markers for
critical code sections, which turn off preemption (suspending if required before
beginning the section).  Such atomic locks will be necessary eventually anyway,
when MOOs move to a distributed architecture.  Others may argue, but I'm
pretty sure they will, sooner or later.  ("They called me mad when I...")

Mike O'Brien