Re: Mutex Problem

Handles should be invalidated by the time CloseHandle returns. Are you sure that you aren't thinking about how the cache manager might retain a reference to a PFILE_OBJECT after handles are closed? (That should not apply to Mutex objects, and in either case should be transparent to the user.)

--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
"lelteto" <lelteto@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:36797D6A-0893-4EE9-919B-4CB66BA2BFD6@xxxxxxxxxxxxxxxx
1. IF you know that one application is the master (and it most work before
the slave can) then yes, you can use CreateMutex in the master and OpenMutex
in the slave. Note, however, that if the slave app starts earlier, then it
would not get the mutex. (Since nothing to process anyway, one option is to
periodically re-try opening the mutex.)

2. Yes, good programming practice requires that each and every application
releases all resources it acquires. And that includes closing ALL handles the
app acquired.

3. On the other hand, Windows should automatically close all handles anyway
when an app terminates. (But are you sure your app fully terminates and the
slave app doesn't sometimes has another - maybe non-functional, but not
temrinated thread running?) You can check wth Task Manager if the slave app
terminated.

4. Note, that Windows may delay closing handles if it thinks it is faster to
keep a resorce open because maybe the same app will use it again. (Although I
don't know how this interferes with the app-termination cleanup part of the
system.)

Laszlo Elteto
SafeNet, Inc.

"עפר" wrote:

Hi All,

I have 2 applications that I need to synchronize their mutual access of some
shared memory, and for this reason each of these applications tries to create
an unowned named-mutex upon its startup:

hMutex = CreateMutex (NULL, false, szMutexName);

From this moment and on, any of them gets hold of the mutex before accessing
the shared memory, and releases it immediately afterwards:

if (WAIT_OBJECT_0 != WaitForSingleObject (hMutex, 1000))
{
return (-1);
}

<access the shared memory>...

ReleaseMutex (hMutex);

NOTE: NONE of the applications call CloseHandle (hMutex)!

To be more accurate, one of them acts as a master (that is, makes both
read/write operations), and the other as a slave (that is, may only read the
shared memory).

Now, everything works fine all along, no matter what's the first application
to run (and create the mutex), and what's the second.

BUT when the slave ends running and closes, the master application only
partially succeeds getting hold of the mutex (that is, sometimes it get hold
of the mutex, sometimes not, in a seemingly repeating way), and therefore
cannot properly funtion.

1) Why is it so, and how can I solve it?

2) Should the slave application close the mutex somehow upon closing?

3) Should I use OpnetMutex() instead of CreateMutex()?

Thanks for your help,
Ofer.



.

Relevant Pages

  • Re: pthread_mutex is not released when process closes
    ... particular mutex, why would the next entity to aquire that mutex care about it? ... I have an app where two separate processes both access a single chunk of shared memory. ... If I were to include a CRC of the data in the shared memory area, then if one of them dies while holding the mutex, the other could easily verify whether the data is self-consistent simply by verifying the CRC. ...
    (comp.programming.threads)
  • RE: Mutex Problem
    ... the slave can) then yes, you can use CreateMutex in the master and OpenMutex ... Note, however, that if the slave app starts earlier, then it ... would not get the mutex. ...
    (microsoft.public.platformsdk.security)
  • Re: How to allow a specific number of Instances of my app?
    ... I may want to allow someone to run my app 3 times on ... there is a problem with a Mutex if the App crashes. ... Fault-tolerance is almost always handled with a classic Watch Dog. ... Use shared memory. ...
    (microsoft.public.vb.general.discussion)
  • Re: pthread_mutex is not released when process closes
    ... particular mutex, why would the next entity to aquire that mutex care about it? ... If I were to include a CRC of the data in the shared memory area, then if one of them dies while holding the mutex, the other could easily verify whether the data is self-consistent simply by verifying the CRC. ... If the app that died corrupted other memory it really doesn't matter to the second app, because the only chunk it cares about would be covered by the mutex. ...
    (comp.programming.threads)
  • Re: IOCP critical sections and mutexes
    ... then there is some bug in your ... routines but I recently started some preliminary stress test on a new server ... then pushes it in a queue that will be later processed by my main app ... If I use a mutex instead it works fine. ...
    (microsoft.public.win32.programmer.kernel)