DOCUMENT:Q84053 04-FEB-2002 [win16ddk] TITLE :How a TSR Can Serialize Access to Its Data PRODUCT :Microsoft Windows Device Driver Kit PROD/VER::3.0,3.1 OPER/SYS: KEYWORDS: ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Windows Device Development Kit (DDK) for Windows, versions 3.0, 3.1 ------------------------------------------------------------------------------- SUMMARY ======= In the enhanced mode of the Microsoft Windows graphical environment, each virtual machine (MS-DOS applications and the Windows system) is scheduled for execution using a preemptive multitasking algorithm. A terminate-and- stay-resident program (TSR) that is visible to all processes running in Windows at any given time (a so-called "global" TSR) must take precautions to prevent two or more processes from accessing its data concurrently. This article discusses techniques that a TSR can use to serialize other applications' access to its data. MORE INFORMATION ================ A TSR can employ any of the following four techniques to prevent conflicts when more than one process accesses data simultaneously: 1. Use the virtual memory manager (VMM) to instance the data in the TSR. This method requires either a virtual device (VxD) or processing the Windows startup broadcast (Interrupt 2Fh Function 1605h) documented in the "Microsoft Windows Device Development Kit Virtual Device Adaptation Guide." This technique creates a copy of the critical data for each virtual machine that requires access. Because each instance has its own private copy, concurrent access to the data is impossible. A TSR cannot use instanced data to share information between virtual machines or to describe a system-wide state for the machine. 2. Encapsulate the global data in a VxD, which performs all data management. This article does not discuss this technique. 3. Use the critical section services described in the "Microsoft Windows DDK Virtual Device Adaptation Guide." 4. Use semaphores. An application can implement the third technique by surrounding each access to the data with calls to the Begin_Critical_Section (Interrupt 2Fh, Function 1681h) and End_Critical_Section (Interrupt 2Fh, Function 1682h) services. However, doing so can cause a significant performance hit for three reasons: 1. Interrupt 2Fh may be trapped by many TSRs or VxDs; traversing the interrupt chain can take a long time. 2. The critical section is claimed by Windows frequently; each call to Begin_Critical_Section may block the process or Windows unnecessarily. 3. If the virtual timer device (VTD) reflects a timer interrupt into a virtual machine while another VM has claimed the critical section, processing blocks. Note: The presence of an owned critical section does not suppress task switches into VMs that receive reflections of hardware interrupts. If the critical section is not required by the TSR for other reasons, the TSR can perform serialization much more efficiently by using a semaphore. A semaphore is a global variable in the TSR than can be maintained using the following code: Wait_On_Sem: mov al,1 xchg al,[Semaphor] ;; xchg is indivisible!!! test al,0ffh je Got_Access ;; If Semaphor was 0, gained access; mov ax,1680h ;; otherwise, int 2fh ;; release time slice jmp short Wait_On_sem ;; and try again. Got_Access: < access the data here > xor al,al ;; Free semaphore. xchg al,[Semaphor] This code uses the variable Semaphor as a binary semaphore that has either the value 1, indicating claimed, or 0, indicating free. Note that this technique depends on the indivisibility of the XCHG instruction. If the processor receives an interrupt while it is processing an indivisible instruction, the processor completes the instruction before processing the interrupt. In this example, the XCHG instruction transfers data between the AL register and the Semaphor variable. If XCHG was not indivisible and an interrupt occurred as the XCHG was being processed, two processes could receive the semaphore simultaneously, which defeats the mutual exclusion that the semaphore is designed to provide. Careful coding is required when using the semaphore because there is always a possibility of deadlocking a process. REFERENCES ========== For more information on semaphores and mutual exclusion in general, refer to an introductory text on operating systems. One such text is "An Introduction to Operating Systems" by Harvey M. Deitel (Addison- Wesley). Additional query words: 3.00 3.10 DDKTSR DDKVXD ====================================================================== Keywords : Technology : kbAudDeveloper kbWin3xSearch kbWinDDKSearch kbWinDDK300 kbWinDDK310 Version : :3.0,3.1 ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2002.