VirtualLock function
Applies to: desktop apps only
Locks the specified region of the process's virtual address space into physical memory, ensuring that subsequent access to the region will not incur a page fault.
Syntax
BOOL WINAPI VirtualLock( __in LPVOID lpAddress, __in SIZE_T dwSize );
Parameters
- lpAddress [in]
-
A pointer to the base address of the region of pages to be locked.
- dwSize [in]
-
The size of the region to be locked, in bytes. The region of affected pages includes all pages that contain one or more bytes in the range from the lpAddress parameter to
(lpAddress+dwSize). This means that a 2-byte range straddling a page boundary causes both pages to be locked.
Return value
If the function succeeds, the return value is nonzero.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Remarks
All pages in the specified region must be committed. Memory protected with PAGE_NOACCESS cannot be locked.
Locking pages into memory may degrade the performance of the system by reducing the available RAM and forcing the system to swap out other critical pages to the paging file. Each version of Windows has a limit on the maximum number of pages a process can lock. This limit is intentionally small to avoid severe performance degradation. Applications that need to lock larger numbers of pages must first call the SetProcessWorkingSetSize function to increase their minimum and maximum working set sizes. The maximum number of pages that a process can lock is equal to the number of pages in its minimum working set minus a small overhead.
Pages that a process has locked remain in physical memory until the process unlocks them or terminates. These pages are guaranteed not to be written to the pagefile while they are locked.
To unlock a region of locked pages, use the VirtualUnlock function. Locked pages are automatically unlocked when the process terminates.
This function is not like the GlobalLock or LocalLock function in that it does not increment a lock count and translate a handle into a pointer. There is no lock count for virtual pages, so multiple calls to the VirtualUnlock function are never required to unlock a region of pages.
Examples
For an example, see Creating Guard Pages.
Requirements
|
Minimum supported client | Windows XP |
|---|---|
|
Minimum supported server | Windows Server 2003 |
|
Header |
|
|
Library |
|
|
DLL |
|
See also
Send comments about this topic to Microsoft
Build date: 2/7/2012
Quoting from a Microsoft developer who points out how wrong this documentation is:
http://blogs.msdn.com/b/oldnewthing/archive/2007/11/06/5924058.aspx
"When you lock memory with VirtualLock it locks the memory into your process's working set. It doesn't mean that the memory will never be paged out. It just means that the memory won't be paged out as long as there is a thread executing in your process, because a process's working set need be present in memory only when the process is actually executing.
(Earlier versions of the MSDN documentation used to say this more clearly. At some point, the text changed to say that it locked the memory physically rather than locking it into the working set. I don't know who changed it, but it was a step backwards.)"
- 3/22/2012
- md77
"Applications that need to lock larger numbers of pages must first call the SetProcessWorkingSetSize function to increase their minimum and maximum working set sizes. The maximum number of pages that a process can lock is equal to the number of pages in its minimum working set minus a small overhead."
Take an example: You need to lock 100 MB of Physical Memory --- which is equal to 25600 pages (on x86 and x64). In order to be able to successfully lock 25600 pages you should first call SetProcessWorkingSetSize with Minimum Working Set Size as 25600 (+8 pages), and Maximum Working Set Size as anything you desire - but not less than the Minimum Working Set Size.
In real world applications, you would ideally set the value of Minimum Working Set Size much larger than 25600 (+8 pages).
- 9/4/2010
- Ankur Kashyap
