Board index » cppbuilder » when to call MapViewOfFile()

2008-06-30 06:50:20 AM
cppbuilder100
Hay guys, just a really quick question.
Post the other week about using Memory Mapped Files and Remy gave me a
really good reply.
Just to summarise, I have a service that creates a MMF. It protects access
to it using a mutex. Client applications wait for the mutex to be release
and then can read the data from the MMF. For the client, remy suggested
this order of operations:
--- application ---
hMapping = OpenFileMapping(FILE_MAP_READ, FALSE, "MyFileMapping");
hMutex = OpenMutex(SYNCHRONIZE, FALSE, "MyFileMappingMutex");
...
// for each read operation...
if( WaitForSingleObject(hMutex, 1000) == WAIT_OBJECT_0 )
{
// Perform read operation on the MMF...
ReleaseMutex(hMutex);
}
...
CloseHandle(hMutex);
CloseHandle(hMapping);
My question is, do you have to call MapViewOfFile() each time you read the
MMF or can it be called once, initially. For example, should it be called
from within the WaitForSingleObject() call? Seems to work either way, just
want to know what is the best practice.
Many thanks in advance,
Mike
 

Mike Collins wrote:
My gut says keeping the map and mutex around
is faster than creating them for every read.
My philosophy is "thrashing" is a Bad Thing.
Doubly so with Windows Resources.
Only potential drawback to keeping them open
would be if the server-writes are slower because
the OS has to update all those open maps.
I don't think that's an actual problem however.
You could also run a server timed test with
the server constantly writting to see if there
is any writting difference between clients
with/without open maps.
 

Hay bob,
Thanks for the reply. Just a quick point.
I wasn't asking becuase of any potential performance issues. What i wanted
to know is if MapViewOfFile() creates a snap shot of the MMF, at that point
in time, or if it is justed used to access the MMF data. If it creates a
snap shot, then as the data changes, reading it again would not make any
differents.
However, it seems to make know difference, although I've stuck the call
within the WaitForSingleObject()
Cheers.
Mike C
"Bob Gonder" < XXXX@XXXXX.COM >wrote in message
 

{smallsort}

Mike Collins wrote:
According to this: File Mapping
msdn.microsoft.com/en-us/library/aa366556(VS.85).aspx
The file exists in only one hunk of RAM
(backed by physical disk space.)
Through Intel CPU Magic, that one hunk of
RAM can be shared at different memory
addresses in different process spaces.
That means if you write to some offset
in your view, you are writing to real,
shared RAM and it is also seen by others
because *it is the same physical RAM*
(Center box in the link.)
I hope that clears it up, does for me :-)