0

I am new to C#, coming from C++ and would like to ask if this is a correct way of using Task Parallel Library.

I have a Web Service which queues long running operations. I don't want to use async web calls, so my idea is to use TPL, creating a task when the web operation is called. I am wondering if there is any kind of a resource leak if I schedule the task from a thread that dies right after the web operation finishes. Let's say that I would not keep a reference to the task as I don't need to check its status nor result. Thanks.

EDIT: Sry, didn't express myself clearly on the first shot. My question is related to web service, not to a client. Client calls the web service operation that takes a long time. Web service call returns saying that operation was successfully queued/executed on background. In the web service operation, I would like to use TPL and not storing a task object returned by StartNew. Wondering, whether the task object is kept forever if I don't read its status and therefore leaking. Maybe it is just my C++ thinking that is getting in the way and I should not take care about the leak given it is managed code.

Peter Vrabel
  • 372
  • 1
  • 8
  • I'd question why you wouldn't want to use async web calls while wondering about resource leaks from a task you create to make web calls. Maybe I'm misunderstanding the question; but it sounds like you want to create a Task from another thread to perform some web call. If resource leaking is a concern and this is what you want to do, why would you "leak" a thread that simply waits for highly-latent IO when you have great asynchronous IO abilities? – Peter Ritchie Sep 18 '12 at 12:41
  • It sounds like you want to queue operations and execute them in the background (presumably via a two way WCF service or some.pilling mechanism). I don't think TPL is ideal for the entire scenario. One is that you probably want a reliable queue, which means some degree of persistence. I would suggest some off-the-shelf queue. If you did that then the queue would deal with threads to execute the operations as well as load balancing, etc. – Peter Ritchie Sep 18 '12 at 13:28
  • But if I use TPL, queuing and executing is pretty much hidden which is one of main points of TPL to my understanding. It uses ThreadPool underneath anyway. The operation just updates a status in database when it finishes so I think using a duplex WCF communication is not needed. Persistent queue is not needed in my case either as the operations can be started using TPL during the web service startup, when it builds up its state from database. I am just worried if starting a task, forgetting a task object and exiting a thread that started the task before the task finished causes any TFLtroubles – Peter Vrabel Sep 18 '12 at 14:24
  • What Queueing do you think TPL does? It does certain load-balancing in certain places; but it doesn't really do any "queueing". e.g. if you "start" long running tasks, there's nothing stopping the TPL from running them all at the same time. You *could* use continuations; but that's really difficult dynamically (i.e. at runtime). e.g. how to do tell task2 to continue after task1 without running into a race condition that task1 finishes before you give it a continuation... – Peter Ritchie Sep 18 '12 at 14:31
  • 1
    Forgetting about a Task doesn't cause the TPL any problems see http://stackoverflow.com/questions/3734280/is-it-considered-acceptable-to-not-call-dispose-on-a-tpl-task-object for more details. But, the work you want to do in that task *is* important--if you "forget about it" how will you know it's been done, done correctly, and doesn't need to be re-started? That's all application specific. – Peter Ritchie Sep 18 '12 at 14:35
  • Queuing in the sense that if thread pool is completely busy, task will be executed later on as soon as thread pool can handle it. Fortunately I can build up tasks' state without any problem when the web service is restarted, but as you said that's application specific. – Peter Vrabel Sep 18 '12 at 15:21
  • Well, "completely busy" for the thread pool means that 1023 thread pool threads have been created and are executing (which would probably be really bad). Otherwise, the thread pool starts out with one thread per CPU/Core as a minimum and maintains that minimum by starting a new thread every second as long as there's isn't that number of non-running threads. So, it really doesn't "queue" anything. e.g. you could start 12 tasks and at point it "queued" 4, at another point it ran all 12... – Peter Ritchie Sep 18 '12 at 15:46
  • @PeterRitchie I voted for your comment as that is exactly what I was looking for, unfortunately I can't mark it as the answer. – Peter Vrabel Sep 19 '12 at 16:08
  • @PeterVrable I've added the detail to an answer that you can vote for... – Peter Ritchie Sep 19 '12 at 16:52

1 Answers1

0

Forgetting about a Task doesn't cause the TPL any problems see stackoverflow.com/questions/3734280/… for more details. But, the work you want to do in that task is important--if you "forget about it" how will you know it's been done, done correctly, and doesn't need to be re-started? That's all application specific.

"completely busy" for the thread pool means that 1023 thread pool threads have been created and are executing (which would probably be really bad). Otherwise, the thread pool starts out with one thread per CPU/Core as a minimum and maintains that minimum by starting a new thread every second as long as there's isn't that number of non-running threads. So, it really doesn't "queue" anything. e.g. you could start 12 tasks and at point it "queued" 4, at another point it ran all 12...

Peter Ritchie
  • 35,463
  • 9
  • 80
  • 98