Subject: Regarding suspend(0) and lag (fwd)

From: [email-masked] (Jeff Prothero)
Date: Mon, 22 Feb 1993 14:33:32 -0800

(Apologies to those who find this uninteresting.  But lags due to lack
of proper pre-emption affect most of the mudding community, so this
seems of sufficiently general interest to warrant general posting for
awhile longer.)

[email-masked]:

| Well, take two copies of a task that work on the same data.  At some point,
| the task will enter a critical section (where it wishes to read and write the
| data, for instance).  Suppose I read the data, then am pre-empted, and then
| you write to the data, then I get the pointer again and I write out the
| data copy I had.  Boom.  Poof.  Your changes are gone.

*nod*.  The generic Databases 101 explanation of why we need to
enforce serializability on transactions...

| That's in an unlocked system, like Moo is now.
| You'd have to add some sort of
| data locking to keep the above from happening.

Clay, I'm still vague on what you are defining as 'locking', and why
you're confident the cure would be worse than the disease.  As someone
who expects to be tackling this problem in a month or so, I have more
than an academic interest in this: If I'm about to waste time trying
to square the circle, I'd just as soon know about it ahead of time.

Back when I took database theory, it was considered sufficient that a
sequence of transactions be serializable: That their total effect be
equivalent to some serial sequence of them.  It was not required that
all transactions actually run in serial sequence non-preemptively, nor
was the implementor required to use explicit or implicit locks.  All
that was required was that serializability be maintained, by whatever
means.

Clay:

(1) Is the serializability criterion used in the database world
    insufficient for the requirements of the mud world for some
    reason?  I don't see why this would be, but I admit it's
    entirely possible within my limited understanding.  You're
    not being very clear on the semantics you're trying to enforce
    (or perhaps I'm being too dense to follow?) so I'm simply
    assuming serializability, without meaning to put words in your
    mouth...

(2) When you say 'locking', are you using the term loosely to
    encompass all possible means of enforcing serialability (or
    whatever semantics you have in mind), or are you specifically
    asserting that nonlocking protocols from the database world
    will fail in the mud context?  I don't see why this would be,
    but again, this may reflect my limited understanding.

| And even then, without good
| programmers, or good hand-holding by the server, you are threatened with
| deadlock.

I'm unclear whether you refer to good application-language
programmers, or good server programmers.  Deadlock is certainly a
problem some serializability mechanisms need to deal with; and in fact
the database world has been doing this for some years now.  (I invite
you to read the literature if you don't believe me.)  Is there
something about the mud environment which makes the problem more
intractable?

| Yuck.

Um.  Is this 'yuck' at the concept of having good programmers around,
or at having "good hand-holding by the server"?  We appear to already
have the former, and if the latter means a well-implemented server
that handles preemptive multi-tasking well, I don't quite follow why
this would be disgusting per se... ?

| Even Unix, a multi-tasking operating system, must bow to the God of 
| Sequentiality.

*blink*.  I confess the point of this comment completely escapes me.
Unix appears to me a nice demonstration of the benefits of pre-emptive
multitasking, I'm running a long compile in the background as I type
this, and am grateful that I don't have to wait for it to finish
before seeing the characters echo.  Yes, unix contains mechanisms to
deal with problems raised by pre-emptive multitasking.  It also plays
host to database systems that implement multithreading internally, and
various other multi-threaded programs.  The success of all this tends
more to incline me to believe that pre-emptive tasking has proven
benefits, than to drive me back to non-preemptive CP/M (say) ... :)

---

From: Pavel Curtis <[email-masked]>
Date: Thu, 25 Feb 1993 10:42:07 -0800

> Date:	Mon, 22 Feb 1993 14:33:32 -0800
> From:	[email-masked] (Jeff Prothero)
> 

I believe that this is the right model for the MOO, as well, but you don't want
to go too far with analogies between the MOO and traditional databases.

> something about the mud environment which makes the problem more

Yes.  The fundamental problem in attempting to solve deadlock and locking
problems automatically on the server is that, unlike in the traditional
database world, it is not possible to statically determine what items in the DB
will need to be locked to run a particular `query'.  Thus, you can't, in
advance, sort all of those resources by the global locking order and then lock
them.  You will therefore have to lock them as they are accessed by the code.
Since most MOO tasks touch a lot of different properties and verbs, and these
are getting locked in more-or-less random order, you can expect a *lot* more
deadlocks than in a traditional DB.

> benefits, than to drive me back to non-preemptive CP/M (say) ... :)

UNIX works as well as it does for multitasking precisely because there is very,
very little in the way of shared data, essentially only files.  UNIX does
provide file locking, but almost no applications use it, so you the human have
to be careful not to try to print the PostScript output of your editor until
you're sure the editor has finished writing the file.  Similar examples of
human mediation of shared data conflicts abound in such an environment.

In UNIX, shared data is the exception, whereas in MOO it is the rule.  This,
along with the need to cater to amateur programmers, makes the MOO a very
unusal kind of OS environment.  One should not be too glib about applying
common solutions from other domains.

	Pavel