0

I want that the single task is automatically disposed after ending.

In this code I run parallel tasks and await their end. After WaitAll, all tasks are disposed together.

Task t1 = Task.Run(() => load_1());
Task t2 = Task.Run(() => load_2());
Task t3 = Task.Run(() => load_3());

Task.WaitAll(t1, t2, t3);
t1.Dispose(); t2.Dispose(); t3.Dispose();
S.L. Barth is on codidact.com
  • 8,198
  • 71
  • 51
  • 66
Cosma Iaffaldano
  • 221
  • 4
  • 13

2 Answers2

0

The answer is, essentially, do nothing to dispose a task. This discussion explains why "do nothing" is correct

Basically you will rely on finalization to take care of the task disposal because from your short example, you're doing nothing extraordinary.

Community
  • 1
  • 1
Kit
  • 20,354
  • 4
  • 60
  • 103
  • [Another stackoverflow discussion on a similar topic](https://stackoverflow.com/questions/3734280/is-it-considered-acceptable-to-not-call-dispose-on-a-tpl-task-object). – user3613932 Jul 06 '17 at 06:35
-1

Tasks almost never have a reason to be disposed, that's automatically done by .NET after the Task returns a completion state and the allocated resources by the Task are no longer needed.

user7386753
  • 41
  • 7
  • 1
    Tasks aren't necessarily tied to a thread in the first place, and you shouldn't think of them as being tied to one. – Servy Mar 06 '17 at 22:32
  • Thank you for your criticism and downvote but that's irrelevant for my answer, the point here is letting OP know that Task disposal is done automatically and he shouldn't worry about it. Also, Tasks are pretty much always tied to a Thread in the ThreadPool unless you're using async. – user7386753 Mar 06 '17 at 23:48
  • You're asserting that the disposal is disposing of the thread. Tasks don't have a thread to dispose of. No, most tasks in most applications aren't going to be tied to a thread. If they are you're probably doing something quite wrong. And of course in the fairly uncommon case that it's *using* a thread, it'll be a thread pool thread and as such it is not something that the `Task` cleans up at all (not that even a regular thread would have anything for the task to clean up). – Servy Mar 07 '17 at 14:24
  • Oh well that is not what I meant. Sorry for the poor phrasing in my answer, english is not my main language, answer has been edited. In the CLR's view programs will always be tied to a Thread which we usually call Main Thread, there is a reason why any C# program can call Thread.Sleep, and therefore Tasks will always be tied to a thread (either one in the ThreadPool or the Main Thread). – user7386753 Mar 07 '17 at 20:11
  • No, tasks *aren't* tied to a thread. A task represent some asynchronous operation. That operation *could* represent a delegate executed in a thread, or it could represent a database query, file IO, a network request, a composite operation of multiple other asynchronous operations, an operation that is itself composed of another asynchronous operation, it could represent an operation that is finished after a period of time, when some event fires, when the OS sends a given signal, and on and on. – Servy Mar 07 '17 at 21:16
  • Did you even read my comment? Tasks have to run somewhere, either synchronously in the same thread as the program (Main Thread) or asynchronously in some thread from the Thread Pool. You can always reference the thread where the Task is running, which will be the Main Thread most of the time, so Tasks are always tied to a thread. Also, Tasks are not required to contain asynchronous operations, and will run synchronously if they can. – user7386753 Mar 07 '17 at 21:58
  • Did you read *my* content? No, a task *doesn't* necessarily represent code being run somewhere. It can represent all sorts of things *that don't represent code running at all*. I just listed a dozen different things that a task can represent that have no relation at all to code running on any thread. Perhaps you want to go read it again. At it's core what a task *is* is an asynchronous operation. You can synchronously wait for it to finish, but it is, by its very definition, an asynchronous operation. It doesn't *contain* an operation, rather it *is* an asynchronous operation. – Servy Mar 07 '17 at 22:05
  • I suppose you're really overthinking here, the fact that you can always reference the Task's current thread proves my point but I'll try to explain it to you again. It doesn't matter what the Task is doing, could be running some local I/O that takes time to complete, executing a Console.WriteLine synchronously or waiting on data from a web server. In any case the Task will generate some code that will tell the CPU to interrupt whatever it's doing and resume your program execution, this code and any code from the Task runs in the Task's thread. – user7386753 Mar 07 '17 at 22:18
  • To make it more clear, again, a program needs a thread to run (Main Thread), a Task runs from a program, the Task will use either the Main Thread or another one from the Thread Pool in order to run. – user7386753 Mar 07 '17 at 22:21
  • There *is* no "way to access the current thread of a task". Task's don't have a thread. `In any case the Task will generate some code that will tell the CPU to interrupt whatever it's doing and resume your program execution, this code and any code from the Task runs in the Task's thread.` No, a `Task` *doesn't* necessarily do that. It's just an asynchronous operation that eventually gets marked as completed somehow. It's not going to interrupt a thread, and the task doesn't even necessarily have any code associated with it that could run on any thread at all. – Servy Mar 07 '17 at 22:22
  • No **that second statement is false**. A Task does *not* need to use the main thread or any thread pool thread in order to run. It can use *no threads at all*. Executing code on a thread is just *one* thing a `Task` can do; one of *many* other possibilities, many of which involve *no threads at all*. – Servy Mar 07 '17 at 22:23
  • Everything that runs inside a computer has to be code in some form, Tasks are no different, even if you are doing something as simple as waiting on a web request it will generate something to handle the completion of that event, and this has to be done inside a thread. Actually, any operations executed by the CLR are done using a thread, that's just how the CLR abstraction works. – user7386753 Mar 07 '17 at 22:26
  • Under the hood there is no thread, this article explains a lot about it http://blog.stephencleary.com/2013/11/there-is-no-thread.html – user7386753 Mar 07 '17 at 22:28
  • Linking to an article about how there is no thread while asserting that all tasks are tied to a thread and that they don't represent executing operations on a thread. – Servy Mar 07 '17 at 22:32
  • There is no thread, threads are an abstraction to help the CPU do multi-tasking. C# code runs in the CLR, and the CLR works on top of the threads abstraction to improve performance and provide async tools, therefore anything running in the CLR is linked to a thread, including Tasks. – user7386753 Mar 07 '17 at 22:37
  • But the whole point is that C# code doesn't even necessarily represent work done in the CLR. It might, and it might not. Or it might represent work done across dozens of threads. Tasks can represent way more than a thread doing some work. That's just *one* thing that they can do. – Servy Mar 07 '17 at 22:41
  • Indeed they can, but Tasks are a C# managed structure and no matter what they're doing the callbacks will always go back to C# code running in the CLR, which means they will always be somehow tied to a thread. – user7386753 Mar 07 '17 at 22:46
  • The fact that a thread is going to need to execute the callback doesn't mean that the task is tied to a thread, or that the operation that the task represents represents work in a thread, contrary to your claim, or that the task somehow needs to "clean up" a thread (a thread executing a method doesn't leave work for that method to "clean up", it just returns and the thread goes on doing whatever it wants to do). – Servy Mar 07 '17 at 22:48
  • Alright you win, thanks for all this knowledge, I'm just a high school kid trying to win a discussion with the little I know. Guess I'll read more about threads and then we can resume this :) – user7386753 Mar 07 '17 at 22:55