是否可以为多次调用MapViewOfFileEx回收地址空间而不会失败? [英] Can address space be recycled for multiple calls to MapViewOfFileEx without chance of failure?

问题描述

请考虑在Windows XP的32位地址空间中运行的复杂的，占用大量内存的多线程应用程序.

Consider a complex, memory hungry, multi threaded application running within a 32bit address space on windows XP.

某些操作需要n个固定大小的大缓冲区，其中一次只需要访问一个缓冲区.

Certain operations require n large buffers of fixed size, where only one buffer needs to be accessed at a time.

应用程序使用一种模式，其中一些地址空间(一个缓冲区的大小)被提前保留，并用于包含当前所需的缓冲区.

The application uses a pattern where some address space the size of one buffer is reserved early and is used to contain the currently needed buffer.

这是按照以下顺序进行的: (初始运行)VirtualAlloc-> VirtualFree-> MapViewOfFileEx (缓冲区更改)UnMapViewOfFile-> MapViewOfFileEx

This follows the sequence: (initial run) VirtualAlloc -> VirtualFree -> MapViewOfFileEx (buffer changes) UnMapViewOfFile -> MapViewOfFileEx

在这里，对VirtualAlloc的调用提供了指向缓冲区位置的指针，然后在对MapViewOfFileEx的每次调用中都使用相同的位置.

Here the pointer to the buffer location is provided by the call to VirtualAlloc and then that same location is used on each call to MapViewOfFileEx.

问题是，据我所知，windows不提供任何握手类型的操作来在不同用户之间传递内存空间.

The problem is that windows does not (as far as I know) provide any handshake type operation for passing the memory space between the different users.

因此(在我上面的序列中的每个->位置)，内存锁定的机会很小，另一个线程可以跳入并在缓冲区内执行分配.

Therefore there is a small opportunity (at each -> in my above sequence) where the memory is not locked and another thread can jump in and perform an allocation within the buffer.

对MapViewOfFileEx的下一次调用已中断，系统不再能够保证地址空间中有足够大的空间用于缓冲区.

The next call to MapViewOfFileEx is broken and the system can no longer guarantee that there will be a big enough space in the address space for a buffer.

显然，重构为使用较小的缓冲区可以减少重新分配空间的失败率.

Obviously refactoring to use smaller buffers reduces the rate of failures to reallocate space.

使用HeapLock取得了一些成功，但这仍然存在问题-仍然设法从地址空间中窃取了一些内存. (我们尝试调用GetProcessHeaps，然后使用HeapLock锁定所有堆)

Some use of HeapLock has had some success but this still has issues - something still manages to steal some memory from within the address space. (We tried Calling GetProcessHeaps then using HeapLock to lock all of the heaps)

我想知道的是，有什么方法可以锁定与MapViewOfFileEx兼容的特定地址空间块吗?

What I'd like to know is there anyway to lock a specific block of address space that is compatible with MapViewOfFileEx?

我应该补充一点，最终该代码存在于一个库中，该库由我控制范围之外的应用程序调用

I should add that ultimately this code lives in a library that gets called by an application outside of my control

推荐答案

您可以强行使用它；暂停进程中不是执行映射的线程的每个线程，取消映射/重新映射，取消暂停已暂停的线程.这不是很优雅，但这是我可以想到的唯一方式，可以提供您所需的那种互斥.

You could brute force it; suspend every thread in the process that isn't the one performing the mapping, Unmap/Remap, unsuspend the suspended threads. It ain't elegant, but it's the only way I can think of off-hand to provide the kind of mutual exclusion you need.

这篇关于是否可以为多次调用MapViewOfFileEx回收地址空间而不会失败?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！