I'm thinking about Mutexes and I need some clarification about them. Should I try to open existing Mutex or create new one (of course both with the same name). Example of code:
First attempt - try open existing one:
private void AttemptOne()
{
Mutex myMutex;
if (!Mutex.TryOpenExisting("Mutex Name", out myMutex))
myMutex = new Mutex(false, "Mutex Name");
try
{
myMutex.WaitOne(3000);
// code
}
catch { }
finally
{
myMutex.ReleaseMutex();
// myMutex.Dispose(); - should I call that or it will be called automatically when returning from method?
}
}
Second attempt - create new Mutex:
private void AttemptTwo()
{
using (Mutex mutex = new Mutex(false, "Mutex Name"))
{
try
{
mutex.WaitOne(3000);
// code
}
catch { }
finally { myMutex.ReleaseMutex(); }
}
}
I have some questions, which bother me:
which attempt to use?
Let assume that I have a background process with created Mutex, and at the same time Main process tries to do some work, which should be blocked until backgorund process finishes. If background process created its own Mutex, should I try to open it?
Or create new Mutex in Main thread with the same name?
What is the difference between those attempts?
should I call Dispose() in first Attempt?
Or just assume that Mutex will be disposed when method returns? Will it be disposed then?
I assume that in second attempt Mutex will be Disposed (as its IDisposable) when using() ends. Am I right?
If you're planning to create the mutex if it doesn't exist anyway, then just go ahead and use the second method.
If you're going for a different behavior based on the existence of the mutex, then you should use TryOpenExisting to check if it exists.
As for your other questions:
Yes, you should call the Dispose or Close method on the mutex when you're done with it. In order to allow the operating system to destroy it once it's not in use.
Yes, using would call the Mutex object Dispose method.
I think you shouldn't use named mutex to synchronize threads in a single process. It's better to share a mutex (or semaphore) object between this threads (in a local variable or in a class field for example). So use named mutex to make process synchronization(for example running only one copy of the application).
About your questions. TryOpenExisting() represent a common pattern TryXxx and provide you opportunity to check the result of an operation without exceptions. Although there are some constructor overloads that have out createdNew boolean parameter you must declare another variable for this what is ugly. Your second variant means that you don't care about whether you have existing mutex or just create a new.
Calling Dispose() (or put the object into using) is always usefull practice. If you use named mutex like in your code all will be fine after disposing. But if you dispose a shared mutex variable (like I advice) in one thread all other threads which waits this mutex will fall with an exception. In this case you should dispose mutex only when you realy sure that you have no needs in it.
As you can see answers on your questions depends on the specific situation.
Related
I have a console application which will be initiated by different batch files set up windows task scheduler. I would like to queue these commands or have some sort of a lock mechanism in my application that would have all the commands waiting on a queue, so that only one command runs at a time. I was thinking about doing some sort of a file lock, but i cant get my head wrapped around to how would it work for queuing commands. I just need some sort of direction.
For inter-process synchronization, you may use a Mutex instance representing a named system mutex.
// Generate your own random GUID for the mutex name.
string mutexName = "afa7ab33-3817-48a4-aecb-005d9db945d4";
using (Mutex m = new Mutex(false, mutexName))
{
// Block until the mutex is acquired.
// Only a single thread/process may acquire the mutex at any time.
m.WaitOne();
try
{
// Perform processing here.
}
finally
{
// Release the mutex so that other threads/processes may proceed.
m.ReleaseMutex();
}
}
Look for Semaphore object.
_resultLock = new Semaphore(1, 1, "GlobalSemaphoreName");
if (!_resultLock.WaitOne(1000, false))
{
// timeout expired
}
else
{
// lock is acquired, you can do your stuff
}
You can always put your timeout to Infinite, but it is practical to get control over the program flow from time to time and be able to abort gracefully.
Let's say I have this class Logger that is logging strings in a low-priority worker thread, which isn't a background thread. Strings are queued in Logger.WriteLine and munched in Logger.Worker. No queued strings are allowed to be lost. Roughly like this (implementation, locking, synchronizing, etc. omitted for clarity):
public class Logger
{
private Thread workerThread;
private Queue<String> logTexts;
private AutoResetEvent logEvent;
private AutoResetEvent stopEvent;
// Locks the queue, adds the text to it and sets the log event.
public void WriteLine(String text);
// Sets the stop event without waiting for the thread to stop.
public void AsyncStop();
// Waits for any of the log event or stop event to be signalled.
// If log event is set, it locks the queue, grabs the texts and logs them.
// If stop event is set, it exits the function and the thread.
private void Worker();
}
Since the worker thread is a foreground thread, I have to be able to deterministically stop it if the process should be able to finish.
Question: Is the general recommendation in this scenario to let Logger implement IDisposable and stop the worker thread in Dispose()? Something like this:
public class Logger : IDisposable
{
...
public void Dispose()
{
AsyncStop();
this.workerThread.Join();
}
}
Or are there better ways of handling it?
That would certainly work - a Thread qualifies as a resource, etc. The main benefit of IDisposable comes from the using statement, so it really depends on whether the typical use for the owner of the object is to use the object for a duration of time in a single method - i.e.
void Foo() {
...
using(var obj = YourObject()) {
... some loop?
}
...
}
If that makes sense (perhaps a work pump), then fine; IDisposable would be helpful for the case when an exception is thrown. If that isn't the typical use then other than highlighting that it needs some kind of cleanup, it isn't quite so helpful.
That's usually the best, as long as you have a deterministic way to dispose the logger (using block on the main part of the app, try/finally, shutdown handler, etc).
It may be a good idea to have the thread hold a WeakReference to the managing object, and periodically check to ensure that it still exists. In theory, you could use a finalizer to nudge your thread (note that the finalizer, unlike the Dispose, should not do a Thread.Join), but it may be a good idea to allow for the possibility of the finalizer failing.
You should be aware that if user doesn't call Dispose manually (via using or otherwise) application will never exit, as Thread object will hold strong reference to your Logger. Answer provided by supercat is much better general solution to this problem.
In my application I have a form that starts synchronization process and for number of reasons I want to allow only one synchronization to run at a time. So I've added a static bool field to my form indicating whether sync is in progress and added a lock to set this field to true if it wasn't already set so that first thread could start synchronization but when it's running every other thread that will try to start it will terminate.
My code is something like this:
internal partial class SynchronizationForm : Form
{
private static volatile bool workInProgress;
private void SynchronizationForm_Shown(object sender, EventArgs e)
{
lock (typeof(SynchronizationForm))
{
if (!workInProgress)
{
workInProgress = true;
}
else
{
this.Close();
}
}
}
}
This is working well but when I run Code Analysis on my project I'm getting the following warning message:
CA2002 : Microsoft.Reliability : 'SynchronizationForm.SynchronizationForm_Shown(object, EventArgs)' locks on a reference of type 'Type'. Replace this with a lock against an object with strong-identity.
Can anyone explain to me what's wrong with my code and how can I improve it to make the warning gone. What does it mean that object has a strong-identity?
What is wrong is that you are locking on something public (typeof(SynchronizationForm)) which is accessible everywhere from your code and if some other thread locks on this same thing you get a deadlock. In general it is a good idea to lock only on private static objects:
private static object _syncRoot = new object();
...
lock (_syncRoot)
{
}
This guarantees you that it's only SynchronizationForm that could possess the lock.
From the MSDN explanation of the rule
An object is said to have a weak identity when it can be directly accessed across application domain boundaries. A thread that tries to acquire a lock on an object that has a weak identity can be blocked by a second thread in a different application domain that has a lock on the same object.
Since you can't necessarily predict what locks another AppDomain might take, and since such locks might need to be marshalled and would then be expensive, this rule makes sense to me.
The problem is that typeof(SynchronizationForm) is not a private lock object, which means that any other piece of code could use it to lock on, which could result in deadlock. For example if some other code did this:
var form = new SynchronizationForm();
lock(typeof(SynchronizationForm))
{
form.SomeMethodThatCausesSynchronizationForm_ShownToBeCalled();
}
Then deadlock will occur. Instead you should delcare a private lock object in the SynchronizationForm class and lock on that instead.
The System.Type object of a class can conveniently be used as the mutual-exclusion lock for static methods of the class.
Source: http://msdn.microsoft.com/en-us/library/aa664735(VS.71).aspx
To add to Doug's answer, what you have here is a locking mechanism which should only be used in static methods, being used in an instance method.
I've been reading up on .NET Threading and was working on some code that uses a ManualResetEvent. I have found lots of code samples on the internet. However, when reading the documentation for WaitHandle, I saw the following:
WaitHandle implements the Dispose
pattern. See Implementing Finalize and
Dispose to Clean Up Unmanaged
Resources.
None of the samples seem to call .Close() on the ManualResetEvent objects they create, even the nice Recursion and Concurrency article from the pfxteam blog (Edit - this has a using block I has missed). Is this just example oversight, or not needed? I am curious because a WaitHandle "encapsulates operating system–specific objects," so there could easily be a resource leak.
I was recently forwarded an excerpt from C# 4.0 in a Nutshell: The Definitive Reference By Joseph Albahari, Ben Albahari. On page 834, in Chapter 21: Threading there is a section talking about this.
Disposing Wait Handles
Once you’ve finished with a wait
handle, you can call its Close method
to release the operating system
resource. Alternatively, you can
simply drop all references to the wait
handle and allow the garbage collector
to do the job for you sometime later
(wait handles implement the disposal
pattern whereby the finalizer calls
Close). This is one of the few
scenarios where relying on this backup
is (arguably) acceptable, because wait
handles have a light OS burden
(asynchronous delegates rely on
exactly this mechanism to release
their IAsyncResult’s wait handle).
Wait handles are released
automatically when an application
domain unloads.
In general, if an object implements IDisposable it is doing so for a reason and you should call Dispose (or Close, as the case may be). In the example you site, the ManualResetEvent is wrapped inside a using statement, which will "automatically" handle calling Dispose. In this case, Close is synonymous with Dispose (which is true in most IDisposable implementations that provide a Close method).
The code from the example:
using (var mre = new ManualResetEvent(false))
{
...
}
expands to
var mre = new ManualResetEvent(false);
try
{
...
}
finally
{
((IDispoable)mre).Dispose();
}
The Close is handled inside ManualResetEvent's Dispose, and that's called by the 'using' statement.
http://msdn.microsoft.com/en-us/library/yh598w02%28VS.100%29.aspx
You'll notice the code
using (var mre = new ManualResetEvent(false))
{
// Process the left child asynchronously
ThreadPool.QueueUserWorkItem(delegate
{
Process(tree.Left, action);
mre.Set();
});
// Process current node and right child synchronously
action(tree.Data);
Process(tree.Right, action);
// Wait for the left child
mre.WaitOne();
}
uses the 'using' keyword. This automatically calls the dispose method when finished even if the code throws an exception.
I've used ManualResetEvent a lot and don't think I've ever used it inside a single method--it's always an instance field of a class. Therefore using() often does not apply.
If you have a class instance field that is an instance of ManualResetEvent, make your class implement IDisposable and in your Dispose() method call ManualResetEvent.Close(). Then in all usages of your class, you need to use using() or make the containing class implement IDisposable and repeat, and repeat...
If you're using a ManualResetEvent with anonymous methods then it's obviously useful. But as Sam mentioned they can often be passed around into workers, and then set and closed.
So I would say it depends on the context of how you are using it - the MSDN WaitHandle.WaitAll() code sample has a good example of what I mean.
Here's an example based on the MSDN sample of how creating the WaitHandles with a using statement would exception:
System.ObjectDisposedException
"Safe handle has been closed"
const int threads = 25;
void ManualWaitHandle()
{
ManualResetEvent[] manualEvents = new ManualResetEvent[threads];
for (int i = 0; i < threads; i++)
{
using (ManualResetEvent manualResetEvent = new ManualResetEvent(false))
{
ThreadPool.QueueUserWorkItem(new WaitCallback(ManualWaitHandleThread), new FileState("filename", manualResetEvent));
manualEvents[i] = manualResetEvent;
}
}
WaitHandle.WaitAll(manualEvents);
}
void ManualWaitHandleThread(object state)
{
FileState filestate = (FileState) state;
Thread.Sleep(100);
filestate.ManualEvent.Set();
}
class FileState
{
public string Filename { get;set; }
public ManualResetEvent ManualEvent { get; set; }
public FileState(string fileName, ManualResetEvent manualEvent)
{
Filename = fileName;
ManualEvent = manualEvent;
}
}
I have a situation where I might have multiple instances of a program running at once, and it's important that just one specific function not be executing in more than one of these instances at once.
Is this the proper way to use a mutex to prevent this from happening?
lock (this.GetType()) {
_log.Info("Doing Sync");
DoSync();
_log.Info("Sync Completed");
}
You said multiple instances of one application, so we're talking about two program.exe's running, right? The lock statement won't lock across multiple programs, just within the program. If you want a true Mutex, look at the System.Threading.Mutex object.
Here is a usage example:
bool createdNew;
using (Mutex mtx = new Mutex(false, "MyAwesomeMutex", out createdNew))
{
try
{
mtx.WaitOne();
MessageBox.Show("Click OK to release the mutex.");
}
finally
{
mtx.ReleaseMutex();
}
}
The createdNew variable will let you know whether or not it was created the first time. It only tells you if it has been created, though. If you want to acquire the lock, you need to call WaitOne and then call ReleaseMutex to release it. If you just want to see if you created a Mutex, just constructing it is fine.
TheSeeker is correct.
Jeff Richter's advice in Clr Via C# (p638-9) on locking is to create a private object specifically for the purpose of being locked.
private Object _lock = new Object();
// usage
lock( _lock )
{
// thread-safe code here..
}
This works because _lock cannot be locked by anything outside the current class.
EDIT: this is applicable to threads executing within a single process. #David Mohundro's answer is correct for inter-process locking.