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模拟器在65529次迭代后将冻结。 这是我做错的事情吗，还是应该注意的平台问题？

谢谢PaulH

编辑：增加到/ STACK：1048576,4096使我可以在设备冻结之前进行65535次迭代。

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

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

Edit4：使用实际文件支持MMF似乎没有什么区别。 > 65535迭代中失败。

Answer 1

在Windows中，内存是在pages中管理的。 此外，分配这些页面时具有最小的粒度。 在桌面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个打开的视图的未记录限制。

-PaulH