MapViewOfFile 冻结 Windows Mobile 6 设备

Question

我有一个适用于 Windows Mobile 6 ARMV4I 的 Visual Studio 2008 C++ 项目，其中使用内存映射文件。不幸的是，它会导致设备锁定。我可以使用以下代码演示该问题：

#include <list>
#include <algorithm>

int _tmain(int argc, _TCHAR* argv[])
{
    DWORD alloc_size = 256;
    DWORD alloc_max = 16 * 1024 * 1024;
    DWORD alloc_count = alloc_max / alloc_size;

    HANDLE f = ::CreateFileMapping( INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, alloc_max, NULL );

    std::list< void* > l;
    for( DWORD i = 0; i < alloc_count; ++i )
    {
        // device freezes after 65529 iterations
        l.push_back( ::MapViewOfFile( f, FILE_MAP_READ | FILE_MAP_WRITE, 0, i * alloc_size, alloc_size ) );
    }

    std::for_each( l.rbegin(), l.rend(), ::UnmapViewOfFile );
    ::CloseHandle( f );
    return 0;
}

在我的测试中，Windows Mobile 6 Classic Emulator 将在 65529 次迭代后冻结。这是我做错了还是有我应该注意的平台问题？

谢谢， PaulH

编辑： 增加到 /STACK:1048576,4096 允许我在设备冻结之前达到 65535 次迭代。

Edit2：根据发生故障之前的GlobalMemoryStatus，设备有 70.5MB / 94.1MB 可用物理内存。

Edit3：我可以创建两个 MMF 并将它们加载到最大 65500 * 256 字节。但是，它们各自的分配量都不能超过 65535。实际上，分配大小并不重要。我可以将其切成两半，每个字节为 128 个字节，但在 > 65535 次迭代中仍然失败。

编辑4：用实际文件支持MMF似乎没有什么区别。 > 65535 次迭代失败。

Answer 1

在 Windows 中，内存是按页面进行管理的。此外，分配这些页面时存在最小粒度。在桌面 Windows 上，一个页面通常为 4KiB，最小粒度通常为 64KiB。如果您尝试 VirtualAlloc 或 MapViewOfFile 的大小小于该值，则会向上舍入，并且您将浪费一些 RAM。

我非常确定 Windows Mobile 上的页面大小也将是 4KiB - 因此对于每个 256 字节的 MapViewOfFile，它实际上必须保留至少 4KiB。您可以调用 GetSystemInfo 自行获取这些号码。

这意味着您的代码实际上预留了至少 256MiB，如果分配粒度更高，则可能会更多。您的应用程序正在耗尽其地址空间。

Answer 2

根据此（参见图 4），只有 256MB 的地址空间分配用于内存映射文件。 64K 分配 * 4KB = 256MB，因此您已达到限制。

Answer 3

我与有权访问消息来源的人进行了交谈。事实证明，MapViewOfFile 使用一个内部引用计数器，即 USHORT。因此，在第 65535 次迭代中，它溢出并引起了各地的仇恨和不满，最终导致系统停止运行。
因此，内存映射文件中存在 65535 个打开视图的未记录限制。

-保罗H