Is Mutex Owned?

  • Thread starter Thread starter Lamont Sanford
  • Start date Start date
L

Lamont Sanford

Given an object of type Mutex, what method or property should be called to
determine if it is currently owned?

I could call WaitOne(0,false) -- and if the return value is false, I could
deduce that the Mutex is already owned... but this has the unwanted side
effect of seizing ownership of the Mutex in the case where the Mutex is NOT
already owned.

I'm looking for something like an "IsOwned" property.
 
Given an object of type Mutex, what method or property should be called to
determine if it is currently owned?

I could call WaitOne(0,false) -- and if the return value is false, I could
deduce that the Mutex is already owned... but this has the unwanted side
effect of seizing ownership of the Mutex in the case where the Mutex is NOT
already owned.

I'm looking for something like an "IsOwned" property.
Click to expand...

Yes, that'd be nice. I use Mutex.OpenExisting (added in .NET 2.0):

public static bool IsMutexOwned(string key)
{
try
{
Mutex.OpenExisting(key);
return true;
}
catch (WaitHandleCannotBeOpenedException)
{
return false;
}
}

Michael
 
Given an object of type Mutex, what method or property should be called to
determine if it is currently owned?

I could call WaitOne(0,false) -- and if the return value is false, I could
deduce that the Mutex is already owned... but this has the unwanted side
effect of seizing ownership of the Mutex in the case where the Mutex is NOT
already owned.

I'm looking for something like an "IsOwned" property.
Click to expand...

I don't think there is one aside from what you just said i.e. check to
see if you grabbed the lock and if so release it immediately. The
complement of the return value indicates whether something else had
the lock. But if you aren't accessing a critical section, why do you
want to know the status of the mutex? Or are you trying to use a
named mutex to prevent multiple copies of your app from running? If
that's the case, there are better ways of doing that...
 
having IsOwned property will not do you much because it may fail after the
check :

if (Mutex.IsOwned("") == false)
{
// if you try to get the mutex here you can fail.
}

This is a common problem, same goes with sockets.IsConnected;
 
having IsOwned property will not do you much because it may fail after the
check :

if (Mutex.IsOwned("") == false)
{
// if you try to get the mutex here you can fail.

}
Click to expand...

.... but it's helpful if you don't need to own the mutex. As an
example, here's how I use my IsOwned() method in a launcher/updater
tool:

if mutex is owned
switch to process owning that mutex
else
modify files used by processes that could own the mutex
launch the process (and only I launch the process)

So while there might be a race condition, the chance is vanishingly
small, as the launcher itself uses a mutex to assure a single instance
of itself.

Michael
 
but you can then view at the different way :-)

if (Mutex.IsOwned(""))
{
/// move to different process
}

this can still crash since the mutex can be free during.
Since you intercorporate with out of process , you should assume it can fail
always - basis for risk analysis.
 
.... but it's helpful if you don't need to own the mutex.
Click to expand...

If you don't need to own the mutex, you don't actually need a mutex in
your design.
As an
example, here's how I use my IsOwned() method in a launcher/updater
tool:

if mutex is owned
switch to process owning that mutex
else
modify files used by processes that could own the mutex
launch the process (and only I launch the process)

So while there might be a race condition, the chance is vanishingly
small, as the launcher itself uses a mutex to assure a single instance
of itself.
Click to expand...

The race condition you care about isn't just between multiple instances
of the launcher. It's also between the launcher and the application it
can modify. Your launcher could look at the mutex and, before it gets a
chance to do anything else, the process that would have created it (and
which could even be resident and executing already) could go ahead and
create it.

Now you're trying to modify files that are in use and launching a second
instance of the same process.

"Vanishingly small" is not a good way to design code. You could make
the code correct, rather than relying on rarity of situations to prevent
bad behavior.

The bottom line here is that if you don't need to actually acquire the
mutex for the code to work, there is likely a better mechanism to
address whatever issue you're trying to address. Conversely, if
acquiring the mutex is required in order for the code to be 100%
reliable, then you should acquire the mutex.

Pete
 
Peter said:
[...]
"Vanishingly small" is not a good way to design code. You could make
the code correct, rather than relying on rarity of situations to prevent
bad behavior.
Click to expand...

And by "could", I meant "should". :)
 
but you can then view at the different way :-)

if (Mutex.IsOwned(""))
{
/// move to different process

}

this can still crash since the mutex can be free during.
Since you intercorporate with out of process , you should assume it can fail
always - basis for risk analysis.
Click to expand...

Doesn't matter. If the mutex is freed between the check and the
launch, the app is simply launched again. The launched process then
checks its own mutex and either continues launching or defers to the
existing process. (I should say that I'm using Process.Start() here)

In this way, the semantics of an IsMutexOwned() method is useful to
me. It's dangerous in some contexts, though, and we agree, on your
underlying point. Analyse your code for possible failures modes.

Michael
 
If you don't need to own the mutex, you don't actually need a mutex in
your design.




The race condition you care about isn't just between multiple instances
of the launcher. It's also between the launcher and the application it
can modify. Your launcher could look at the mutex and, before it gets a
chance to do anything else, the process that would have created it (and
which could even be resident and executing already) could go ahead and
create it.

Now you're trying to modify files that are in use and launching a second
instance of the same process.
Click to expand...

Point taken. It still is so unlikely to happen in my workflow as to
be unworthy of consideration (we force users to exit before making the
update available for download, and that forced exit period, at least
several minutes, is orders of magnitude greater than the window of
vulnerability you highlight above), but you've pointed out a weakness
in my general approach. Mea culpa.

Michael
 
Or are you trying to use a named mutex to prevent multiple copies of your
app from running? If that's the case, there are better ways of doing
that...
Click to expand...

Actually, yeah, that's what I was using it for... but consider this:

I'm attempting to own the Mutex in the context of a fairly large try{}
block. The finally{} handler performs a ReleaseMutex() and Close()... but
ReleaseMutex() should only be called if the Mutex is actually owned by the
executing process. I need to know whether the Mutex is owned (by my
currently executing process) before attempting to release it.

I could always set and check my own internal bool variable ('isMutexOwned'),
and that works just fine, but it just struck me as odd that the Mutex didn't
provide an IsOwned property -- similar to the IsReaderLockHeld property of
the ReaderWriter lock.
 
Lamont said:
Actually, yeah, that's what I was using it for... but consider this:

I'm attempting to own the Mutex in the context of a fairly large try{}
block. The finally{} handler performs a ReleaseMutex() and Close()... but
ReleaseMutex() should only be called if the Mutex is actually owned by the
executing process. I need to know whether the Mutex is owned (by my
currently executing process) before attempting to release it.
Click to expand...

A mutex is owned by a thread, not a process. Using a named mutex you
can accomplish inter-process synchronization, but it's still a specific
thread within the process that owns the mutex.

This may or may not be relevant in your own case (e.g. it wouldn't
matter for a single-threaded application), but it's worth pointing out IMHO.
I could always set and check my own internal bool variable ('isMutexOwned'),
and that works just fine, but it just struck me as odd that the Mutex didn't
provide an IsOwned property -- similar to the IsReaderLockHeld property of
the ReaderWriter lock.
Click to expand...

For what it's worth, the property you seem to want is significantly
different from the property that most (if not all) of us assumed you
wanted. That is, you seem to be asking for a way to know if the
executing thread is actually the one holding the mutex. This is a lot
different from simply wanting to know if the mutex is being held by
_any_ thread (in-process or otherwise).

Now, all that said...it seems to me that if you don't want to keep a
local variable to track whether you've successfully acquired the mutex
or not, you should simply acquire the mutex _before_ the
try/catch/finally block of code. IMHO, code protected by a mutex (or
other synchronization object, for that matter) should generally look
like this:

if (/* successfully acquire object */)
{
/* Do some work */

/* release acquired object */
}

In other words, the object "protects" a section of code, and at the very
end of that section, you release the object. So, instead of this:

bool fHaveObject = false;

try
{
if (/* successfully acquire object */
{
fHaveObject = true;

/* Do some work */
}
}
finally
{
if (fHaveObject)
{
/* release acquired object */
}
}

You should have something like this:

if (/* successfully acquire object */)
{
try
{
/* Do some work */
}
finally
{
/* release acquired object */
}
}

You may have to nest try/finally blocks to use that pattern (depending
on what else the code is doing), but IMHO if you have a block of code so
large that's a problem, you probably are dealing with some code that
ought to be broken into multiple methods anyway.

If that specific pattern doesn't work in your case, and you would like
something different than what you actually have, you might consider
posting the block of code that's giving you trouble. I'll bet someone
will have an idea of a different way to do it. :)

Pete
 
Thanks, Pete. The explanation was very helpful.

I'm learning some great stuff from this newsgroup.
 
Back
Top