Global Lock Count Changes in Windows 3.x

Last reviewed: July 22, 1997
Article ID: Q61285
3.00 3.10 WINDOWS kbprg

The information in this article applies to:

  • Microsoft Windows Software Development Kit (SDK) for Windows versions 3.1 and 3.0

SUMMARY

The global lock count mechanism has been changed in the Windows version 3.x protected modes (that is, standard mode and enhanced mode). The GlobalLock function only affects the lock count of discardable objects and the default data segment (DGROUP); movable objects are not affected. Thus, repeated calling of GlobalLock() and GlobalFlags() on a GMEM_MOVEABLE object does not show any changes to its lock count.

MORE INFORMATION

The following are reasons and explanations concerning this design change:

  1. In real mode, GlobalLock() fixes the segment:offset of a global memory object. It also increases the lock count, as reported by GlobalFlags().

  2. In protected mode, the far pointer returned by GlobalLock() is a selector:offset, not a segment:offset. Because the selector value does not change, GlobalLock() does not actually fix the memory object in the physical address space. Thus, the GlobalLock function in protected mode does not change the lock count, unless the object is discardable or is a default data segment.

    In the case of a discardable object, the lock count is meaningful, because Windows needs to know when the object can be discarded (which is when its lock count is zero).

  3. However, some applications have used the GlobalLock() lock count as a "reference count" [that is, as an indication of how many times GlobalLock() was called]. If the lock count for an object goes to zero, these applications might consider the object a candidate for being manually discarded, perhaps after copying the data to disk.

    Unfortunately, this use of GlobalLock() as a reference count keeper does not work in protected mode. Applications that symmetrically pair calls to GlobalLock() with calls to GlobalUnlock() do not need to know the lock count, and therefore, are unaffected by this change in behavior.

  4. How does an application keep track of reference counts now, given that the GlobalLock() approach does not work for nondiscardable objects in protected mode? The application should really keep track of reference counts itself, which should not be hard to do because the application in need of this functionality will have a table of global handles anyway.

    However, if the application cannot be modified to maintain its own reference counts, then there is a new Windows function, called GlobalFix(), that will accomplish this functionality. GlobalFix() performs the following functionality:

    a. It fixes the object in the protected mode linear space.

    b. It increments the "lock count", as returned by the

          GlobalFlags function.
    

  5. The following includes more information about GlobalFlags(). In real mode, it returns the GlobalLock() lock count. In protected mode, if the object is discardable, GlobalFlags() also returns the GlobalLock() lock count. In protected mode, if the object is nondiscardable, GlobalFlags() returns the GlobalFix() reference count. In other words, GlobalFlags() always returns the lock/fix count. However, in protected mode, the GlobalLock() and GlobalUnLock() APIs do not affect the count, only the GlobalFix() and GlobalUnFix() APIs do.

    NOTE: In real mode, the GlobalFlags() lock count actually indicates the sum of GlobalLock()'s and GlobalFix()'es. Therefore, if the programmer is calling GlobalLock() and GlobalFix() in pairs, then the GlobalFlags() lock count actually is twice the logical reference count, if in real mode.

  6. If the application needs to keep track of reference counts, and the programmer wants Windows to do the work for them, then the programmer must accompany every call to GlobalLock() with a call to GlobalFix(). This way the programmer will be able to depend on the validity of the GlobalFlag() lock/reference count. However, using the GlobalFix() API just to keep track of the reference count is overkill, if that is all the programmer wants it to do. Remember, GlobalFix() also fixes the object in the protected mode linear address space. The price the programmer pays for having Windows keep track of the reference count (by using the GlobalFix()) is the following:

    a. Every time the GlobalLock() or GlobalUnLock() API is called,

          the programmer must also call either the GlobalFix() or
          GlobalUnFix().
    

    And, much worse:

    b. The programmer establishes sandbars in the linear address space.

    An application should either keep track of reference counts on its own or always pair GlobalLock() calls with matching GlobalUnlock() calls; the use of the GlobalFix() API should be avoided.

    Very few applications should need to fix global objects in linear space; therefore, few applications should need to use the GlobalFix function.

  7. If the programmer needs to unconditionally unlock and free a global memory object of any type, then code similar to the following can be used:

            /* 1.  Make it discardable if necessary. */
            if (GlobalFlags shows that it is nondiscardable)
                GlobalRealloc (GMEM_MODIFY it to be discardable);
    
            /* 2. Remove any lock counts that might be on it. */
            while (GlobalUnlock != 0) /* keep unlocking it */
                ;
    
            /* 3. Free it. */
            GlobalFree()
    


Additional reference words: 3.00 3.10
KBCategory: kbprg
KBSubcategory: KrMm
Keywords : kb16bitonly


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.

Last reviewed: July 22, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.