What is the use for a Mutex if you can't name it?

Question

I am having a hard time figuring out what good a mutex is without naming it. Specifically I want to make my Windows Mobile 6.5 app single-instance.

There are a few questions and answers on this site about how to do that - and the best ones seem to use named mutexes.

Unfortunately the CTORS for mutexes in compact framework do not take a string - one can only create a mutex.

Now, what good is a mutex if it has no associated ID?

Am I missing something?

How do I use a mutex to protect a resource across multiple applications if I can't name them?

Stigmatic

Yeah, there's a bunch of simple stuff that should be in .NET CF but isn't. You need only peruse the MSDN docs for all the classes and methods without the silly little device icon. Guess we should all thank Microsoft for making more work and keeping our jobs secure. – Telemark

This is a related question: #867550 – Lashondra

Answer 1

In the compact framework itself, no there is not.

What is the use for a Mutex if you can't name it?

An unnamed mutex is said to be a local mutex. You can still use it for synchronizing between different threads in the same process. A monitor like the lock keyword doesn't have the same amount of functionality. As ctacke notes, a Mutex does not allow recursive entrance. Also, a monitor cannot be used across AppDomain boundaries. Additionally, a Mutex can be used with helpful things like WaitHandle.WaitAll or WaitAny, where a monitor cannot be used with any of those things.

Am I missing something?

No - In the .NET CF Framework you cannot name a mutex without the help of platform invoke.

How do I use a mutex to protect a resource across multiple applications if I can't name them?

You have to name them - and you can do that, you just have to resort to some platform invoke. Windows CE based system have supported named mutexes for a while. You could write a P/Invoke call that does it yourself:

[DllImport("Coredll.dll")]
public static extern IntPtr CreateMutex(IntPtr lpMutexAttributes, bool initialOwner, string lpName);

And use it as (for example) CreateMutex(IntPtr.Zero, false, "MutexName");

You would also have to write P/Invoke calls for ReleaseMutex and CloseHandle.

---

Specifically I want to make my Windows Mobile 6.5 app single-instance.

A named mutex is one solution. Another solution that may work for you is to use a file lock.

1. Create a file named foo.txt on start up if it doesn't exist.
2. Acquire a write lock on the file file using FileShare.None.
3. A different instance will not be able to aquire a write lock on it since the first instance has a lock on it and won't share it. Catch the exception and terminate the program since one is already running.

4. When the program closes, clean up the lock. Even if the process crashes or terminates abnormally, the lock on the file should be removed allowing another instance to start. Something like this:

   FileStream stream;
   try
   {
        stream = new FileStream("lock.txt", FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.None);
   }
   catch
   {
       MessageBox.Show("Program is already running.");
       return;
   }
   //Put your application code here.
   MessageBox.Show("Program is now running.");
   stream.Close();
   

Junitajunius

This only answers one of the four questions asked (including the title). "Am I missing something?" But what good is an unnamed mutex? – Filippa

@JeffreyLWhitledge Added some more details. – Junitajunius

probably worth at least noting that Mutex is far slower than a Monitor as well. – Lashondra

The file lock is a really cool alternative. – Bipetalous

Answer 2

The difference between a Monitor (which lock is syntactic sugar for) and a Mutex is subtle, especially when you're looking at a single process. A Monitor can be re-entered by the acquiring thread. A Mutex cannot. So if you have a recursive algorithm that say calls something asynchronously (yes this is a contrived example, but it should be enough to see the idea), you can prevent multiple overlapping async calls with a Mutex, but not with a Monitor.

Lashondra

OK. But this is a pretty brain-dead "Mutex" that they implemented in CF. It would have been better to leave it out altogether IMO. If they can't implement a real mutex, then why bother I guess was my point. – Stigmatic

They didn't do a whole lot of implementing. It's a wrapper around the CreateMutex API. They simply didn't add the most useful overload. Why, we can only guess. – Lashondra