when to call MapViewOfFile()

Thread View: borland.public.cppbuilder.nativeapi

4 messages

[T] Back to Threads [V] Tree View [G] Group Articles

4 total messages Started by Mike Collins Sun, 29 Jun 2008 22:50

#164

Author: Mike Collins
Date: Sun, 29 Jun 2008 22:50

33 lines
1951 bytes

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

Re: when to call MapViewOfFile()

#165

Author: Bob Gonder
Date: Sun, 29 Jun 2008 23:44

23 lines
1696 bytes

Mike Collins wrote:

>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.

I'd say run a timed test both ways.

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.

Re: when to call MapViewOfFile()

#173

Author: Mike Collins
Date: Mon, 30 Jun 2008 23:41

19 lines
1646 bytes

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" <none@nowhere.invalid> wrote in message 
news:eb6g641bfr1olgbgf3lqrjd0avnclmj9bo@4ax.com...

Re: when to call MapViewOfFile()

#175

Author: Bob Gonder
Date: Tue, 01 Jul 2008 01:40

20 lines
1560 bytes

Mike Collins wrote:

>What i wanted to know is if MapViewOfFile() creates a snap shot of the MMF,

No, it is dynamic....

According to this: File Mapping
http://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 :-)

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads