From: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: What does locking memory do?
Date: 19 Oct 1997 06:35:27 GMT
Organization: The National Capital FreeNet
Lines: 42
Message-ID: <62c9nf$lgj@freenet-news.carleton.ca>
References: <01bcdc22$9423bc60$b95d29c0 AT worldwii>
Reply-To: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
NNTP-Posting-Host: freenet5.carleton.ca
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk


"Dave" (cgileadi AT itsnet DOT com) writes:
> What is the purpose of locking memory?  I am new to 32 bit programming, and
> I saw the  locking functions and have heard of them being used, and I am
> curious.

Locking memory makes sure the memory is in physical RAM all the time and
not on disk swap. There are 2 reasons for locking memory. One, you may
lock a frequently accessed object or lookup table so it is never swapped
out to improve performance. The other, more important use, is dealing with
exception handlers and interrupt code. (E.g. Allegro timer routines you
set up with install_int().) Most function calls and data accesses in
protected mode involve something that checks for the stuff being on disk
and swapping it in if necessary; this won't work when the function is
called, or the data accessed at unpredictable times like interrupts or
timers and not when the program sequence reaches a particular instruction.
If memory read or written to by a function, and the function itself, are
not all locked, and the function is, or is called in an exception/timer
handler... kaboom. You'll get erratic, unpredictable hangs and crashes and
lockups, and the more memory in use, the more weird crap. And as far as
end users a concerned, a program with such behavior is a non-starter.


> Could not locking be the reason my program keeps crashing on my blit code? 
> It sometimes works and sometimes doesn't...

If the blit is called from, or involves, interrupts, timer interrupts,
video interrupts, or exceptions, it's a definite suspect. If not, then
it's defintiely not that, and I'd look for such goofs as

* Writing through a bad/NULL pointer
* Writing past the end of an array

Those are the most likely suspects in blitting code.
Also, blit code to video memory must be using farptr functions. Make sure
these pointers are valid also.

--
    .*.  Where feelings are concerned, answers are rarely simple [GeneDeWeese]
 -()  <  When I go to the theater, I always go straight to the "bag and mix"
    `*'  bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh