Реализация файла с отображением памяти std :: allocator приводит к зависанию устройства WM6

Question

У меня есть проект Visual Studio 2008 C ++ для Windows Mobile 6.x, где мне нужно больше памяти, чем доступно в слоте процесса 32 МБ. Итак, я ищу использование файлов с отображением памяти. Я создал стандартную реализацию распределителя, которая заменяет new / delete на CreateFileMapping и MapViewOfFile .

Предполагаемое использование выглядит примерно так:

родовое слово

С помощью std::allocator я могу получить 28197 итераций в этом примере, прежде чем я получу исключение std::bad_alloc. Используя код MappedFileAllocator, я получаю 32371 итерацию, прежде чем устройство полностью зависнет и его придется перезагрузить. Поскольку у моего устройства 512 МБ ОЗУ, я ожидал, что смогу получить гораздо больше итераций из этого цикла.

Моя реализация сгенерированного кода кода:

родовое слово

Может ли кто-нибудь подсказать, где я могу ошибиться с моей реализацией кода MappedFileAllocator?

Спасибо, PaulH

Answer 1

Я только что получил значок "популярный вопрос" на этот вопрос, поэтому решил (с опозданием) опубликовать ответ.У меня заканчивались доступные ручки.В ядре Windows Mobile есть беззнаковый короткий счетчик, относящийся к переполненному выделению дескрипторов.Как только это произойдет, устройство зависнет.

Answer 2

Проверьте, поддерживает ли boost :: interprocess Windows Mobile.У них есть средства для создания файлов с отображением памяти и использования памяти для выделения любого фрагмента данных, который вы хотите:

http://www.boost.org/doc/libs/1_47_0/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.mapped_file

Answer 3

Вы используете анонимное сопоставление файлов (без фактического файла, поддерживающего его).Когда вы это сделаете, сопоставление поддерживается файлом системной страницы.Вероятно, что в мобильной ОС на самом деле нет файла подкачки, потому что «жесткий диск», вероятно, является флэш-устройством.Как правило, делать подкачку виртуальной памяти на флэш-устройства - плохая идея, потому что природа виртуальной памяти означает большой объем записи, которая может быстро сжечь флэш-память (особенно старые типы).

Похоже, это подтверждается количеством выполняемых итераций.Похоже, вы можете сопоставить до 60% общей памяти вашего устройства.

Вы, вероятно, сможете заставить это работать с большими разделами, если откроете реальный файл (с помощью OpenFile) и сопоставите его, а не используете INVALID_FILE_HANDLE в CreateFileMapping.Но будьте осторожны со своим флеш-хранилищем (и с производительностью!), Если вы собираетесь очень много писать в сопоставление файлов.