[adn258]

So I've heard different opinions about this that you only need to call dispose on a task if you use waiting on the task etc. Then others say don't dispose. I also can't dispose if I just use the general Task.Factory.StartNew so I'm wondering if it matter the following code is a segment I'm using in my program

  Task.WaitAll(Task.Factory.StartNew(() =>
                    {
                        foreach (string ifile in ifiles)
                        {
                            DoGUIAction(() => this.LstBxFilesToConvert.Items.Add(ifile));
                            Thread.Sleep(5);
                        }
                    }));

Should I be worried about disposing of this task I don't know? When should I be worried? This is confusing. Thanks guys.

[lordofduct]

Disposing of a Task is useful if the Task you're waiting on stalls for whatever reason.

Let's say your task performs an action that could cause that Tasks thread to not complete in time (infinite, or a long time). It could be a spin lock, an infinite loop, it's waiting on another task that takes to long... and you want to just stop the task all together. Dispose will help you do that by destroying it.

Why this pertains to 'Wait' is because if the task enters such a state, than the thread scope that is waiting is going to also hang.

Dispose in general just destroys the task all together. Seeing as C# and .Net are memory managed, we don't get to decide when an object is finally destroyed and removed. So even when you set the reference to null, the object persists in memory doing it's thing until the garbage collector takes it out. Dispose is a function that'll put the object into a null state, stopping all it's actions and releasing resources, so that while it sits in limbo it doesn't waste major resources or worse, effect running code.

Calling 'Dispose' doesn't have some simple "case all" scenario for it. You call it when it's necessary. So your statement of "you only need to call dispose on a task if you use waiting on the task etc." is a rather naive statement. No, you call dispose if you need the task to be destroyed.

[Curtis Rutland]

Quote

Dispose is a function that'll put the object into a null state, stopping all it's actions and releasing resources, so that while it sits in limbo it doesn't waste major resources or worse, effect running code.

Just a point of clarification, that's not always true. Dispose does whatever the programmer decided to write in the IDispose.Dispose method. It should prepare the object for removal, doing things like closing unmanaged resources like streams and the like, and it should dispose of any IDisposable components that it owns. It should also suppress Finalization, since it should already dispose of the unmanaged resources.

One thing I always clarify to new programmers is that Dispose does not actually release any memory itself. Only the garbage collector does that.

[adn258]

So I need a little more help with this here I almost got this down too thanks for you guys. I get scared now about memory leaks and stuff now is it acceptable to use using on a factory task like so

using (Task.Factory.StartNew(() =>
                                {
                                    cts.Cancel();
                                })) ;

You will not this is an actual piece of code I'm currently using. For some reason it cancels the banckground worker faster. That said is it acceptable to use using on that? Also the code compiles fine but I get a suggestion in Visual Studio that says on the same line the })); is on that there's a possibly empty statement why is that? My line of thinking since I've heard from others is that using using on a task is good if it's for a prolonged thing and in this case the cancel takes WAY longer without the using so hopefully my line of thinking is right? Thanks again guys +1?

[AdamSpeight2008]

Cancellation isn't automatic. The task has to cooperatively take part in cancelling what ever it is doing.

See the example in MSDN Documentation on Cancellation. (Link)

[[email protected]]

Quote

I get a suggestion in Visual Studio that says on the same line the })); is on that there's a possibly empty statement why is that?

That's because the using statement you posted has no body. This:

using (Task.Factory.StartNew(() =>
                                {
                                    
                                })) ;

should be:

using (Task.Factory.StartNew(() =>
                                {
                                    
                                })) { }

Quote

That said is it acceptable to use using on that?

No, it's not. The Task will run asynchronously, meaning you will start the Task.StartNew() in the using statement, the work will be queued to the thread pool, and then StartNew() will return, and you code will continue running beyond the using statement.

What does this mean?

Well, it means that the Task will probably be disposed of before it has finished your work. As we discussed with the BackgroundWorker thread, this isn't a good idea. It is especially not a good idea with tasks, as you will get an InvalidOperationException if you Dispose() of the Task before it has run to completion, faulted, or being canceled.

Bottom line is, you can't use the using statement with asynchronous operations in the way you have there. Well, not unless you are using the asynchronous language support added in C# 5.0

EDIT: Here is a pretty good summary of the situation with Task.Dispose() from Stephen Toub, member of the PFX team at Microsoft.

This post has been edited by [email protected]: 03 August 2012 - 02:36 AM

[adn258]

Sheer genius codingsupernaturally lol that makes sense. It sounds to me like I've become almost too paranoid with this whole dispose and using( thing. I will talk to you later guys sorry about this.

[[email protected]]

Quote

It sounds to me like I've become almost too paranoid with this whole dispose and using( thing

Yeah, I think you have become a bit paranoid about it all Although, it's better to be a bit paranoid, than just not caring. There is not so much emphasis on memory management in a managed environment like .NET, but it is still important to be vigilant, but not to over think things too much.

Quote

I will talk to you later guys sorry about this.

Don't be sorry about questioning things. That's how we learn, and it's good that you care enough to question things.

This post has been edited by [email protected]: 03 August 2012 - 12:42 PM
Reason for edit:: Changed code tags to quote tags

[Curtis Rutland]

It's good to see people focused on learning. That's really a big deal in these days where people just want the answers handed to them. I really respect it.

On the other hand, you're doing exactly what's called "premature optimization", based on this and your other threads. You're so worried about finding the most efficient algorithm that you're spending more time than you'll ever save CPU cycles.

It's good that you've learned all this about tasks and parallelization, so now you can make smart choices about your programs. But don't focus on finding the most efficient way of doing things. Solve the problem the most logical way, test (and scale your testing) to determine if you need to increase performance, then worry about improving.