|
| Home |
|
|
Win32 Memory Mapped FilesIn conjunction with On Time's file system RTFiles-32 and with paging and the virtual memory manager enabled, RTTarget-32 supports memory mapped files through Win32 API functions CreateFile, CreateFileMappingA, MapViewOfFileEx, OpenFileMappingA, MapViewOfFile, FlushViewOfFile, and UnmapViewOfFile. Although any number of mapped files and views to such mapped files are supported, no two file views should span the same region of a single file. If CreateFileMapping is called with parameter hFile equal to INVALID_HANDLE_VALUE, RTTarget-32 creates a unique temporary file to backup all views of the respective mapping object. The file is created in the directory specified by environment variable TEMP, TMP, or (if neither has been specified using the SET command), in the default directory. The file is deleted automatically when the file mapping object is closed. The total amount of address space of all mapped file views cannot exceed 2G bytes. Initially, a newly created mapped file view requires no physical memory. However, the page table may need to be extended using physical memory to completely cover the file view. For example, the creation of a file view of 1G bytes will require the page table to be extended by 1M bytes. If this amount of physical memory is not available, MapViewOfFile will fail. As the application accesses a file view, physical pages are mapped into the view and the requested pages are read from the mapped file. This process can allocate all available RAM. However, please note that other memory allocation subsystems have priority over memory mapped file. If, for example, a heap manager needs to allocate memory, and no physical memory is available, pages currently mapped to file views may be unmapped to satisfy the allocation request. In this way, memory mapped files always cache as much file data as possible with the currently available physical RAM without reducing the amount of RAM available to the application's heap. When no more physical memory is available, RTTarget-32 will reuse pages which have not been accessed the longest time. Pages of all currently mapped file views participate in this algorithm. Memory mapped files are completely thread safe. Any number of threads can access one or more file views with read and read/write access. FlushViewOfFile can execute in parallel to other threads accessing a mapped file, but it will only flush pages which were dirty at the time FlushViewOfFile was called. Memory mapped files implement true virtual memory, making an address space larger than physical memory available to applications. However, the real-time behavior of an application using memory mapped files is not affected. File swapping occurs at the thread priority of the thread accessing the file view and can be interrupted by interrupts and by higher priority threads. Address space not located in a memory mapped file view (e.g., program code, data, stack, or heap) is never swapped. CreateFileMapping parameter flProtect is ignored, but the MapViewOfFile[Ex] dwDesiredAccess parameter is respected (except value FILE_MAP_COPY). Interrupt handlers should not access a file view's address space. For best performance, it is important to configure RTFiles-32 such that the FAT file chain of all memory mapped files fits into the buffer cache. The FMapDemo demo program, for example, allocates 256 buffers for best performance. Larger mapped files may require more buffers. Please see demo programs FMapDemo and VMemDemo for examples of using memory mapped files.
|
