I want to trigger a task to run on a background thread. I don't want to wait on the tasks completion.
In .net 3.5 I would have done this:
ThreadPool.QueueUserWorkItem(d => { DoSomething(); });
In .net 4 the TPL is the suggested way. The common pattern I have seen recommended is:
Task.Factory.StartNew(() => { DoSomething(); });
However, the StartNew() method returns a Task object which implements IDisposable. This
seems to be overlooked by people who recommend this pattern. The MSDN documentation on the Task.Dispose() method says:
"Always call Dispose before you release your last reference to the Task."
You can't call dispose on a task until it is completed, so having the main thread wait and call dispose would defeat the point of doing on a background thread in the first place. There also doesn't seem to be any completed/finished event that could be used for cleanup.
The MSDN page on the Task class doesn't comment on this, and the book "Pro C#2010..." recommends the same pattern and makes no comment on task disposal.
I know if I just leave it the finalizer will catch it in the end, but is this going to come back and bite me when I'm doing lots of fire & forget tasks like this and the finalizer thread gets overwhelmed?
So my questions are:
Is it acceptable to not call Dispose() on the Task class in this case? And if so, why and are there risks/consequences?
Is there any documentation that discusses this?
Or is there an appropriate way of disposing of the Task object that I've missed?
Or is there another way of doing fire & forget tasks with the TPL?
There is a discussion about this in the MSDN forums.
Stephen Toub, a member of the Microsoft pfx team has this to say:
Task.Dispose exists due to Task
potentially wrapping an event handle
used when waiting on the task to
complete, in the event the waiting
thread actually has to block (as
opposed to spinning or potentially
executing the task it's waiting on).
If all you're doing is using
continuations, that event handle will
never be allocated
...
it's likely better to rely on finalization to take care of things.
Update (Oct 2012)
Stephen Toub has posted a blog titled Do I need to dispose of Tasks? which gives some more detail, and explains the improvements in .Net 4.5.
In summary: You don't need to dispose of Task objects 99% of the time.
There are two main reasons to dispose an object: to free up unmanaged resources in a timely, deterministic way, and to avoid the cost of running the object's finalizer. Neither of these apply to Task most of the time:
As of .Net 4.5, the only time a Task allocates the internal wait handle (the only unmanaged resource in the Task object) is when you explicitly use the IAsyncResult.AsyncWaitHandle of the Task, and
The Task object itself doesn't have a finalizer; the handle is itself wrapped in an object with a finalizer, so unless it's allocated, there's no finalizer to run.
This is the same kind of issue as with the Thread class. It consumes 5 operating system handles but does not implement IDisposable. Good decision of the original designers, there are of course few reasonable ways to call the Dispose() method. You'd have to call Join() first.
The Task class adds one handle to this, an internal manual reset event. Which is the cheapest operating system resource there is. Of course, its Dispose() method can only release that one event handle, not the 5 handles that Thread consumes. Yeah, don't bother.
Do beware that you ought to be interested in the task's IsFaulted property. It's a fairly ugly topic, you can read more about it in this MSDN Library article. Once you deal with this properly, you should also have a good spot in your code to dispose the tasks.
I'd love to see someone weigh on the technique shown in this post: Typesafe fire-and-forget asynchronous delegate invocation in C#
It looks like a simple extension method will handle all trivial cases of interacting with the tasks and be able to call dispose on it.
public static void FireAndForget<T>(this Action<T> act,T arg1)
{
var tsk = Task.Factory.StartNew( ()=> act(arg1),
TaskCreationOptions.LongRunning);
tsk.ContinueWith(cnt => cnt.Dispose());
}
So I have a game object that contains a class A (extends monobehavior) that contains(creates) a class B (no monobehavior). This class B spawns a thread that contains a while (true) loop which does some work.
My question is...
When this GameObject is disposed/destroyed , I assume the class B contained inside of it is destructed as well. When this class B is destructed, is this infinite loop thread terminated as well?
Threads that have been started, principally run until the main thread ends. This is a OS level fallback, to avoid Zombie Threads without a owning application. However, it is not a fallback you should rely on. A Thread once started should be seen as a unmanaged resource, so cleanup code should be in place. The Dispose pattern in particular.
There is this wonderfull article on how to do it, but I feel it needs a explanation. You generally have to differentiate two cases with the Dispose pattern:
You are working with a Unamanged resource directly. In that case you write the Finalizer first. Then provide Dispose as a convenient way to clean stuff up on a programmers decision.
You are handling or may be handling something that implements IDisposeable. In that case, all you implement is the Dispose part and for the sole purpose of cascading teh call down to the Disposeable stuff you wrap around.
95% of all classes only implement IDisposeable because of case 2. We do not know if there actually is anything Disposeable, or if that was just part of a abstract base class.
Thread does not implement Dispose (I have no idea why), so you got a rare case 1. Dispose and Finalizer are often also compressed into one method - usually the Dispose one - as their code is very similar. The only real difference between Finalize and Dispose is cascading behavior:
When Finalizing, you never cascade. Finalisation is between this instance and the GC.
When Disposing, you always cascade (when possible). Most of the cases it is only there to allow cascading.
My final advice is, that since you are working with Multithreading you have to take care not to swallow Exceptions. Normally you got to write really bad code for to swallow Exceptions, but with Multitasking you have to go out of your way to not swallow any. I can not find any indication that Thread has a build in mechanic to persist exceptions (I know for a fact that Task does). All I can give you is the two articles on exception handling I link often:
https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/
https://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET
I'm pretty new in TPL, and I'd like to get an answer to the question :
What is a task lifecycle? when will it end or collected in C#?
If the task is created for a single use - it does its one-time work and then completed - do I need to cancel it?
does the garbage collector collect it?
Here is an example:
DoSomething()
{
Task task = Task.Factory.StartNew(()=>DoOneTimeWork());
}
Is there anyone who can tell me what happened to the local task after DoOneTimeWork is ended?
Thanks a lot!
Since you asked about GC, I'll answer, but as I say I don't think it's particularly interesting and I'd be more concerned about any unobserved exceptions caused by your code, since you neither expose a reference to the task yourself nor queue any further interactions with it via ContinueWith.
At the point at which Task.Factory.StartNew returns (although Task.Run is usually preferred these days), the runtime system will have created a task and will be maintaining a strong reference to that task. Until DoOneTimeWork has completed, either normally or abnormally, that reference at least will prevent the Task object from being collected.
Once DoOneTimeWork has completed, the Task will be updated to record its completion status and the runtime will no longer maintain a reference. Since DoSomething never reads from task, and (as stated above) no other references to the Task would appear to be possible, then even if DoSomething is still running, the Task will now be eligible for collection, at some future point in time1.
When that collection will occur is of course not known deterministically. For all we know, your code is running in a custom CLR with the Zero Garbage Collector and so may in fact never be collected.
do I need to cancel it?
No, cancellation in TPL is cooperative. It involves the use of CancellationTokens, and once cancellation has been requested, code running within the Task needs to have access to the cancellation token and to implement some logic to make cancellation occur.
If the specific Task has already completed then it's not in a position to be running any further code, and so even if your code was using a CancellationToken and requested cancellation, it won't end up cancelled and doesn't need to be.
1Which is just about the same story for any other managed object in the runtime - once all strong references to the object are no longer reachable from GC roots then the object will become eligible for collection2. That's why I said I don't think it's particularly interesting.
2Or finalization and collection, for objects with finalizers, with all the usual caveats around that.
I have the following code:
using (Mutex mut = new Mutex(false, MUTEX_NAME))
{
if (mut.WaitOne(new TimeSpan(0, 0, 30)))
{
// Some code that deals with a specific TCP port
// Don't want this to run at the same time in another process
}
}
I've set a breakpoint within the if block, and ran the same code within another instance of Visual Studio. As expected, the .WaitOne call blocks. However, to my surprise, as soon as I continue in the first instance and the using block terminates, I get an exception in the second process about an abandoned Mutex.
The fix is to call ReleaseMutex:
using (Mutex mut = new Mutex(false, MUTEX_NAME))
{
if (mut.WaitOne(new TimeSpan(0, 0, 30)))
{
// Some code that deals with a specific TCP port
// Don't want this to run twice in multiple processes
}
mut.ReleaseMutex();
}
Now, things work as expected.
My Question: Usually the point of an IDisposable is it cleans up whatever state you put things in. I could see perhaps having multiple waits and releases within a using block, but when the handle to the Mutex is disposed, shouldn't it get released automatically? In other words, why do I need to call ReleaseMutex if I'm in a using block?
I'm also now concerned that if the code within the if block crashes, I'll have abandoned mutexes lying around.
Is there any benefit to putting Mutex in a using block? Or, should I just new up a Mutex instance, wrap it in a try/catch, and call ReleaseMutex() within the finally block (Basically implementing exactly what I thought Dispose() would do)
The documentation explains (in the "Remarks" section) that there is a conceptual difference between instantiating a Mutex object (which does not, in fact, do anything special as far as synchronization goes) and acquiring a Mutex (using WaitOne). Note that:
WaitOne returns a boolean, meaning that acquiring a Mutex can fail (timeout) and both cases must be handled
When WaitOne returns true, then the calling thread has acquired the Mutex and must call ReleaseMutex, or else the Mutex will become abandoned
When it returns false, then the calling thread must not call ReleaseMutex
So, there's more to Mutexes than instantiation. As for whether you should use using anyway, let's take a look at what Dispose does (as inherited from WaitHandle):
protected virtual void Dispose(bool explicitDisposing)
{
if (this.safeWaitHandle != null)
{
this.safeWaitHandle.Close();
}
}
As we can see, the Mutex is not released, but there is some cleanup involved, so sticking with using would be a good approach.
As to how you should proceed, you can of course use a try/finally block to make sure that, if the Mutex is acquired, that it gets properly released. This is likely the most straightforward approach.
If you really don't care about the case where the Mutex fails to be acquired (which you haven't indicated, since you pass a TimeSpan to WaitOne), you could wrap Mutex in your own class that implements IDisposable, acquire the Mutex in the constructor (using WaitOne() with no arguments), and release it inside Dispose. Although, I probably wouldn't recommend this, as this would cause your threads to wait indefinitely if something goes wrong, and regardless there are good reasons for explicitly handling both cases when attempting an acquire, as mentioned by #HansPassant.
This design decision was made a long, long time ago. Over 21 years ago, well before .NET was ever envisioned or the semantics of IDisposable were ever considered. The .NET Mutex class is a wrapper class for the underlying operating system support for mutexes. The constructor pinvokes CreateMutex, the WaitOne() method pinvokes WaitForSingleObject().
Note the WAIT_ABANDONED return value of WaitForSingleObject(), that's the one that generates the exception.
The Windows designers put the rock-hard rule in place that a thread that owns the mutex must call ReleaseMutex() before it exits. And if it doesn't that this is a very strong indication that the thread terminated in an unexpected way, typically through an exception. Which implies that synchronization is lost, a very serious threading bug. Compare to Thread.Abort(), a very dangerous way to terminate a thread in .NET for the same reason.
The .NET designers did not in any way alter this behavior. Not in the least because there isn't any way to test the state of the mutex other than by performing a wait. You must call ReleaseMutex(). And do note that your second snippet is not correct either; you cannot call it on a mutex that you didn't acquire. It must be moved inside of the if() statement body.
Ok, posting an answer to my own question. From what I can tell, this is the ideal way to implement a Mutex that:
Always gets Disposed
Gets Released iff WaitOne was successful.
Will not get abandoned if any code throws an exception.
Hopefully this helps someone out!
using (Mutex mut = new Mutex(false, MUTEX_NAME))
{
if (mut.WaitOne(new TimeSpan(0, 0, 30)))
{
try
{
// Some code that deals with a specific TCP port
// Don't want this to run twice in multiple processes
}
catch(Exception)
{
// Handle exceptions and clean up state
}
finally
{
mut.ReleaseMutex();
}
}
}
Update: Some may argue that if the code within the try block puts your resource in an unstable state, you should not release the Mutex and instead let it get abandoned. In other words, just call mut.ReleaseMutex(); when the code finishes successfully, and not put it within the finally block. The code acquiring the Mutex could then catch this exception and do the right thing.
In my situation, I'm not really changing any state. I'm temporarily using a TCP port and can't have another instance of the program run at the same time. For this reason, I think my solution above is fine but yours may be different.
One of the primary uses of a mutex is to ensure that the only code which will ever see a shared object in a state which doesn't satisfy its invariants is the code which (hopefully temporarily) put the object into that state. A normal pattern for code which needs to modify an object is:
Acquire mutex
Make changes to object which cause its state to become invalid
Make changes to object which cause its state to become valid again
Release mutex
If something goes wrong in after #2 has begun and before #3 has finished, the object may be left in a state which does not satisfy its invariants. Since the proper pattern is to release a mutex before disposing it, the fact that code disposes a mutex without releasing it implies that something went wrong somewhere. As such, it may not be safe for code to enter the mutex (since it hasn't been released), but there's no reason to wait for the mutex to be released (since--having been disposed--it never will be). Thus, the proper course of action is to throw an exception.
A pattern which is somewhat nicer than the one implemented by the .NET mutex object is to have the "acquire" method return an IDisposable object which encapsulates not the mutex, but rather a particular acquisition thereof. Disposing that object will then release the mutex. Code can then look something like:
using(acq = myMutex.Acquire())
{
... stuff that examines but doesn't modify the guarded resource
acq.EnterDanger();
... actions which might invalidate the guarded resource
... actions which make it valid again
acq.LeaveDanger();
... possibly more stuff that examines but doesn't modify the resource
}
If the inner code fails between EnterDanger and LeaveDanger, then the acquisition object should invalidate the mutex by calling Dispose on it, since the guarded resource may be in a corrupted state. If the inner code fails elsewhere, the mutex should be released since the guarded resource is in a valid state, and the code within the using block won't need to access it anymore. I don't have any particular recommendations of libraries implementing that pattern, but it isn't particularly difficult to implement as a wrapper around other kinds of mutex.
We need to understand more then .net to know what is going on the start of the MSDN page gives the first hint that someone “odd” is going on:
A synchronization primitive that can also be used for interprocess
synchronization.
A Mutex is a Win32 “Named Object”, each process locks it by name, the .net object is just a wrapper round the Win32 calls. The Muxtex itself lives within the Windows Kernal address space, not your application address space.
In most cases you are better off using a Monitor, if you are only trying to synchronizes access to objects within a single process.
If you need to garantee that the mutex is released switch to a try catch finally block and put the mutex release in the finally block. It is assumed that you own and have a handle for the mutex. That logic needs to be included before release is invoked.
Reading the documentation for ReleaseMutex, it seems the design decision was that a Mutex should be released consciously. if ReleaseMutex isn't called, it signifies an abnormal exit of the protected section. putting the release in a finally or dispose, circumvents this mechanism. you are still free to ignore the AbandonedMutexException, of course.
Be aware: The Mutex.Dispose() executed by the Garbage collector fails because the garbage collection process does not own the handle according Windows.
Dispose depends on WaitHandle to be released. So, even though using calls Dispose, it won't go into affect until the the conditions of stable state are met. When you call ReleaseMutex you're telling the system that you're releasing the resource, and thus, it is free to dispose of it.
For the last question.
Is there any benefit to putting Mutex in a using block? Or, should I just new up a Mutex instance, wrap it in a try/catch, and call ReleaseMutex() within the finally block (Basically implementing exactly what I thought Dispose() would do)
If you don't dispose of the mutex object, creating too many mutex objects may encounter the following issue.
---> (Inner Exception #4) System.IO.IOException: Not enough storage is available to process this command. : 'ABCDEFGHIJK'
at System.Threading.Mutex.CreateMutexCore(Boolean initiallyOwned, String name, Boolean& createdNew)
at NormalizationService.Controllers.PhysicalChunkingController.Store(Chunk chunk, Stream bytes) in /usr/local/...
The program uses the named mutex and runs 200,000 times in the parallel for loop. Adding using statement resolves the issue.
I am creating a wrapper for a COM library that interacts with IBM mainframes. It can only be accessed from a single thread. To get around this, I've created a System.Windows.Threading.Dispatcher to handle running all interactions on a dedicated thread.
My problem is that if the object is not disposed explicitly, the dispatcher stays running after a WinForm application exits. The finalize method is never called for the object that creates the dispatcher. I need the sessions to be closed reliably to prevent unnecessary connections.
If I call GC.Collect on application exit, it will close fine. However, the library that I created will be used by mostly inexperienced developers. I cannot count on them always Disposing, collecting garbage or all committing to either WinForms or WPF to hook into application exit events.
I've read that if a class has a finalizer, its cleanup gets deferred until later. That may be part of the issue, but I can get around having a finalizer?
The finalize method is never called for the object that creates the dispatcher
The finalizer is called, when GC decides to perform grabage collection. You shouldn't rely on finalizer, when you need to dispose resources explicitly, because you shouldn't interfere in GC work.
I cannot count on them always Disposing
I'm afraid, you have no choice. Implement IDisposable and force your users to call Dispose. This is normal practice in .NET.
Using WPF's dispatcher in a Winforms app isn't exactly a great idea. Check this answer for the equivalent Winforms approach.
Getting the COM objects released otherwise doesn't take a great effort. Just set the thread's IsBackground property to true. Which will make the CLR automatically abort the thread when the program's main thread exits. The CLR then runs one final garbage collection, the exact equivalent of you calling GC.Collect() explicitly.