Xref: news-dnh.mv.net comp.os.msdos.djgpp:1637 Path: news-dnh.mv.net!mv!news.sprintlink.net!europa.chnt.gtegsc.com!cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!news.sesqui.net!rice!news!sandmann From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: Please define "locking" Date: Fri, 18 Aug 1995 14:58:23 CDT Organization: Rice University, Houston, Texas Lines: 51 References: <412kkg$s0p AT sulawesi DOT lerc DOT nasa DOT gov> Reply-To: sandmann AT clio DOT rice DOT edu Nntp-Posting-Host: clio.rice.edu To: djgpp AT sun DOT soe DOT clarkson DOT edu Dj-Gateway: from newsgroup comp.os.msdos.djgpp > 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).