• C

After CreateFileMapping, MapViewOfFile , what next ?

how to put messages into the shared memory i just created ?
Who is Participating?
alexoConnect With a Mentor Commented:

Start with:
    HANDLE hMutex = CreateMutex(NULL, FALSE, "mutex name");

Immediately before accessing the shared memory do:
    WaitForSingleObject(hMutex, INFINITE);

Immediately after accessing the shared memory do:

That's all!

Make sure you use the same mutex name in all processes.
You don't put "messages" into shared memory, you put bytes there.
Seriously, shared memory is treated [almost] like regular mory by the program.  You write to it and read it via the provided pointer (the "almost" bit is because you sould protect shared memory with a mutex to be on the safe side).

After you call MapViewOfFile, the pointer you get is the pointer pointed to the shared memory, (the HANDLE can be used in different prcocess (program), if the pointer is called pView, use *(pView+100) to modfiy it, after that you should use unmapview to save it.
Hopefully, this is what you want?
Good Luck
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

SkyWolfAuthor Commented:
How to protect it using mutex ? can i have some sample codes or something so that i can understand better ?
SkyWolfAuthor Commented:
what about semaphores ? where and when to include ? b4 mutex or after mutex ?
relasemutex right after i do a processing  ?
>> what about semaphores?
No no no.  I probably wasn't clear enough.  Let's try again:

You should use *either* a mutex *or* a semaphore, *not* both.  A semaphore is more versatile than a mutex (a mutex can be treated as a semaphore with a maximum caount of 1) but for your needs, a mutex is suficient (and probably more efficient).

Now, let's go over the process in more details:

Assume you have several processes (programs) that want to access a shared resource (in your case, shared memory).  Here is the skeleton for the apps:

First, decide on the size of the shared memory you want to use:

    #define SIZE 100 /* 100 bytes in shared memory */

Then, create the shared memory (backed by the swap file) and a mutex (for synchronizing access to the shared memory):

    HANDLE  hMapping;
    HANDLE  hMutex;
    PBYTE   pMem;

                                 0, SIZE, "My File Mapping");

    pMem = (PBYTE)MapViewOfFile(hMapping, FILE_MAP_ALL_ACCESS, 0, 0, 0);

    hMutex = CreateMutex(NULL, FALSE, "My Mutex");

That takes care of the initialization.

Now, in some place in the program you want to access the shared memory.  First, you acquire the mutex:

    WaitForSingleObject(hMutex, INFINITE);

Note that the thread will block until the mutex is free.

Then, you access the memory (knowing that no other process (or thread) can reach this point because the mutex is locked):

    pMem[10] = 42; /* or anything similar... */

When you done accessing the memory, you release the mutex which enables another process (or thread) to aquire it:


Finally, at the end of the program you do some cleanup:


That's all!

Just make sure that *every* access to the shared memory (or any other shared resource) is guarded by the mutex.  If you have several shared resources, you may wish to use several mutexes to improve cocurrency.
SkyWolfAuthor Commented:
alexo, can u also go thru with the process of semaphore in details ? i tink i need to create multiple access thanks alot.
SkyWolf, you DON'T NEED a semaphore if you use a mutex (just as you don't need a pick-up truck to get to work if you already have a family car).

You use the mutex for multiple access.  My previous comment was very detailed.  I told you step by step what needs to be done.  Do you feel that I omitted anything?  What exactly?
SkyWolfAuthor Commented:
semaphore is more versatile in what sense ? how versatile ? coz i hav a set of program code that uses BOTH which makes me quite confuse since i do not know much on memory programming stuf ..
SkyWolfAuthor Commented:
and i just want to check with u that coding semaphore is the same coding as Mutex ? now i juz want to compare my truck and my car ... *smile* ... if semaphore is more capable than mutex, i tink i will opt for semaphore...there must be some difference of capability between these two functions right ? else there wont b a need for 2 different function names ...but i may b wrong
>>  i just want to check with u that coding semaphore is the same coding as Mutex

Ah, now I understand.  Let's start with the mutex, it's simpler.

Have you read Goldring's "the lord of the flies"?  It's about a bunch of kids that get stranded on an island and develop a society of sorts.  Anyway, to keep order in their meetings they got a sea-shell and decided that only the person that holds the shell can speak, all the others have to wait until the shell is available.

A mutex is exactly like that sea shell.  A thread can request ownership of a mutex.  Only one thread can own the mutex so if two threads try to do that, one will succeed and the other one will be blocked until the mutex is released.

Incidently, the name "mutex" comes from the fact that it is useful in coordinating MUTually EXclusive access to a shared resource.

A semaphore, if we continue the analogy, is like a box of shells.
A semaphore has a counter.  As long as the counter is greater than zero, the semaphore is available("signalled").  When a thread waits on a semaphore the counter is decremented.  When the counter reaches zero any subsequent thread that tries to wait on the semaphore will get blocked until the counter is increased.

The semaphore object is useful in controlling a shared resource that can support a limited number of users.  It acts as a gate that limits the number of threads sharing the resource to a specified maximum number.  For example, an application might place a limit on the number of windows that it creates.  It uses a semaphore with a maximum count equal to the window limit, decrementing the count whenever a window is created and incrementing it whenever a window is closed.  The application specifies the semaphore object in call to one of the wait functions before each window is created.  When the count is zero (indicating that the window limit has been reached) the wait function blocks execution of the window-creation code.

As you can see, mutexes and semaphores are used for different purposes.  There are several differences:  Threads do not acquire ownership of semaphore objects as they do with mutex objects.  A thread that owns a mutex object can wait repeatedly for the same mutex object to become signaled without its execution becoming blocked.  A thread that waits repeatedly for the same semaphore object, however, decrements the semaphore's count each time a wait operation is completed; the thread is blocked when the count gets to zero.  Similarly, only the thread that owns a mutex can successfully call the ReleaseMutex() function, though any thread can use ReleaseSemaphore() to increase the count of a semaphore object.

So, in your case, a mutex is clearly the correct object to use.
SkyWolfAuthor Commented:
Thanks a lot !
how can I find u or seek your expertise in future ? e-mails ?
Thansk again and if u do not wish to be consulted again ,well ,thanks again !
>> how can I find u or seek your expertise in future ? e-mails ?
Either here or by email.  Click on the link to my info.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.