Is Mutex Owned?

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

[mpetrotta]

On Sep 26, 8:03 am, "Lamont Sanford" <yaBigDu...@san ford.sonwrote:

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.

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

public static bool IsMutexOwned(st ring key)
{
try
{
Mutex.OpenExist ing(key);
return true;
}
catch (WaitHandleCann otBeOpenedExcep tion)
{
return false;
}
}

Michael

[Doug Semler]

On Sep 26, 12:03 pm, "Lamont Sanford" <yaBigDu...@san ford.sonwrote:

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.

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

[Lamont Sanford]

>

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

Interesting technique. Thanks for the tip.

[Ido Samuelson]

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.IsConne cted;

<mp*******@gmai l.comwrote in message
news:11******** **************@ 19g2000hsx.goog legroups.com...

On Sep 26, 8:03 am, "Lamont Sanford" <yaBigDu...@san ford.sonwrote:

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

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

public static bool IsMutexOwned(st ring key)
{
try
{
Mutex.OpenExist ing(key);
return true;
}
catch (WaitHandleCann otBeOpenedExcep tion)
{
return false;
}
}

Michael

[mpetrotta]

On Sep 26, 8:36 am, "Ido Samuelson" <ido.samuel...@ gmail.comwrote:

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.

}

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

[Ido Samuelson]

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.

<mp*******@gmai l.comwrote in message
news:11******** *************@d 55g2000hsg.goog legroups.com...

On Sep 26, 8:36 am, "Ido Samuelson" <ido.samuel...@ gmail.comwrote:

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

}

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

[Peter Duniho]

Peter Duniho wrote:

[...]
"Vanishingl y 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.

And by "could", I meant "should". :)

[mpetrotta]

On Sep 26, 9:25 am, "Ido Samuelson" <ido.samuel...@ gmail.comwrote:

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.

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

[Lamont Sanford]

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

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 IsReaderLockHel d property of
the ReaderWriter lock.