Mail Archives: djgpp/1995/08/19/00:11:30
> Anyway, I've noticed that several recent posts about interrupts (dpmi, go32,
> etc.) have talked about "locking" parts of code, writing the interrupt
> handlers in GAS so as to handle the locking better, etc. What does this mean?
> And, how is it related to "paging"--another subject I know little about?
Paging is what happens when you use virtual memory and are trying to use
more memory than you really have. It puts some of your code and/or data
on the disk temporarily. The hardware of the 386+ chips supports this
memory virtualization, and generates a "page fault" when you try to touch
memory which isn't present in memory (and probably on disk).
The problems start when you have a hardware interrupt routine, and some
of the code and/or data you want to access in that hardware interrupt routine
happens to have been paged out to disk when you ran out of memory.
Since DOS is used to read/write the memory contents to resolve the page
fault, you have a problem. First, you need to read from the disk
(which requires that the interrupt controller be cleaned up) to get another
nested HW interrupt before the first is done. Second, DOS is non-reentrant,
so if you are in the middle of a DOS call when the page fault request happens
you can't even call DOS to do the read. BTW, if you don't lock pages,
get a HW interrupt which generates a page fault while in DOS, you may
nuke your partition table or FAT, which is VERY BAD.
So, you don't want anything you will touch in a hardware interrupt routine
to every get paged out to disk (including the code,data,stack). If you have
enough memory on your machine that you never page (or have disabled virtual
memory) this is not a problem. If you do page, the DPMI page locking
services are a way to tell the paging mechanism to never take those pages
out of memory, and avoid the problem.
> I said above, I wrote a couple generally successful interrupt routines without
> knowing this, and I wonder if they are just accidents waiting to happen?
If they only run on machines you have control over, and you never run them
in a tight memory situation, this isn't a problem. But the consequences of
being wrong about it are potentially a completely trashed hard disk.
Since it's very difficult to track down every memory address you might touch
in C, this is why you start worrying about GAS code so you have control over
the location of the code and data so you know exactly what to lock. The
simple fix is to buy more memory (for everyone :-) so paging is eliminated.
> I realize these may be complex, low-level subjects not quickly explainable,
> but I would appreciate it if someone could please give me a start and/or point
> me to an in-depth (yet understandable) resource?
In-depth and understandable are mutually exclusive with DOS extenders :-)
I would suggest a 386/486/Pentium Programmer reference manual as a start,
then get a copy of the DPMI spec. The "rules" in the DPMI spec are there
for a good reason (like those stated above).
- Raw text -