From: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.os2.advocacy
Subject: Re: OS/2 bigot meets NT....
Date: 26 Dec 92 22:47:01 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <1992Dec27.011721.23160@unvax.union.edu>, pallantj@unvax.union.edu (Joseph C. Pallante) writes:
> I have a question....
> 
> All this debate is over:  Many, Many crashes because a PC has only
> 8 megs of RAM.
> 
> My question:  Why does NT crash (or OS/2 for that matter) because of lack
> of enough RAM?  I would expect it to be slow because the OS would have
> to manipulate the memory, do some swapping, etc...   But, if it follows
> all the rules it should, theoreticaly, it should not crash.  It should
> just take longer to do its job, due to the overhead of running on
> a machine with little memory.

Not true.

You are correct that the OS should not have a `hard' crash (as in a
memory protect violation or the like) in a low-memory situation, and
that if it does it indicates a bug in the OS.

But a `soft' crash, where the system just seems to `go away' indefinitely,
is still possible.  The problem is that in situations where one or another
resource is overcommitted, you can often reach situations where in order
for the OS to proceed, _every_ _process_ on the OS requires something that
is already owned by another process.  This is known as a deadlock or a
deadly embrace.  In general, the only ways to avoid this in all cases
either require that there be a large excess of resources (and that the
system enforce that a program can't use more of its quota of resources
and that the sum of all the quotas isn't more than the total on the
system), or to greatly increase the complexity (and CPU requirements) of
using the API.  These are usually not considered practical solutions
because they greatly increase the amount of resources required on the
system to avoid a problem that's pretty rare anyway except in very
overcommitted situations;  the problem rarely happens in `slightly'
overcommitted systems.

Even on a virtual memory system, the system still needs a certain amount
of real memory in order to run itself, map I/O buffers, and keep track of
virtual memory, etc.  If the system is sufficiently overcommited on memory,
it may not be able to do all these things with available memory and in
fact may encounter situations where every process within the system is
waiting for memory currently in use by another process to be freed.

This is somewhat similar to problems with semaphore deadlocks, where
each process is trying to acquire a semaphore owned by another process;
but semaphores are usually system-level data structures that require
some kind of privilege to use, and this plus the facts that there are
usually relatively few semaphores and that a specific protocol can be
used when allocating and freeing semaphores, mean that the semaphore
problem is more tractable than the memory starvation problem.  For one
thing, user tasks can contribute directly or indirectly to memory
starvation problems;  this is not usually the case with semaphores
when they are properly used.

You're correct that as things deteriorate in low-memory conditions, that
things get slower and slower.  But it's quite possible for things to come
to a complete halt too -- which is what they're talking about.

Bruce C. Wright
Newsgroups: comp.os.os2.advocacy,comp.os.ms-windows.advocacy