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

From: Clay Luther <[email-masked]>
Date: Mon, 22 Feb 1993 13:52:28 -0800

Forwarded message:
> 
> [email-masked]:
> | I'd prefer it not to be "fixed."  There is a certain safety in the current
> | way of during things - that being, you are always certain that (if you
> | don't suspend()) your data will not change beneath you.
> |
> | If preemption was added to the server, you'd have to add memory protection
> | and locking as well.  Yuck.
> 
> Hmm.  I frankly can't imagine switching to a non-premptive unix.  *grin*.
> I'd be curious for a concise proof of the "you'd have to add memory protection
> and locking as well.  Yuck." assertion, and/or an explanation of why this
> merits a 'yuck'.  I'd not want the application-level programmer to have to
> deal much with locking, but I can't see a clear proof that this is needful.
> Then again, it's been a decade or two since I studied this stuff, possibly
> Clay is more up to speed on this than I ... ?

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.

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.  And even then, without good
programmers, or good hand-holding by the server, you are threatened with
deadlock.

Yuck.

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

-- 
Clay Luther                              [email-masked]
Software Engineer                        Vortech Data, Inc.
(214) 994-1377                           Fax (214) 994-1310

I dunno.