When should a Taks be considered Longrunning?

Question

When should a Task be considered Longrunning?
TaskCreationOptions.LongRunning
If it runs for secs, minutes, hours, days?

Dim getDataTask = New Task(Of Generic.List(Of Object))(Function() GetData(pagedQuery, cancellationToken), cancellationToken)Dim continuation As Task = getDataTask.ContinueWith(Sub(antedecent) DisplayData(antedecent.Result, cancellationToken), cancellationToken, TaskContinuationOptions.None, TaskScheduler.FromCurrentSynchronizationContext)

Ex:
I am prototyping a data browser over WCF Data Services.
The user can open as many browser windows as he likes.
To show the data a use a Task to get the data from the service and a continuation Task to get show the data in a grid:Should I define the GetData Task as Longrunning and the DisplayData Task as not Longrunning?

Answer 1

If my understanding is right, LongRunning is a hint about how long it takes to execute efectively, and not waiting for someone else. So none of them will qualify for LongRunning.

Best regards,
Tibi

---

MCT, MCDBA, MCSD.NET, MCPD 2.0(*.*), MCPD 3.5(*.*)

Answer 2

And what length of effectively computing does qualify for LongRunning?

Answer 3

It's not a specific length per se.  If you're generating a lot of tasks, LongRunning is not appropriate for them.  If you're generating one or two tasks that will persist for quite some time relative to the lifetime of your application, then LongRunning is something to consider.  In general, don't use it unless you find that you really need it.  Under the covers, it's going to result in a higher number of threads being used, because its purpose is to allow the ThreadPool to continue to process work items even though one task is running for an extended period of time; if that task were running in a thread from the pool, that thread wouldn't be able to service other tasks.  You'd typically only use LongRunning if you found through performance testing that not using it was causing long delays in the processing of other work.

Answer 4

Stephen,

A couple question regarding this -

From your description, it sounds like a Task flagged as LongRunning causes the Task to not use a ThreadPool thread?  Is the Task generated via a standard Thread, in that case?  Or does it just cause the ThreadPool to add one extra thread for the long running task?

Is there a disadvantage of using a single long running task instead of a self-managed thread if I was going to make a thread that would exist for (nearly) the entire lifetime of the application?  The new task debugging capabilities really make the thought of a long running task seem nicer than a self-created Thread - just wondering if there are any disadvantages to this approach.

-Reed

---

Reed Copsey, Jr. - http://reedcopsey.com

Answer 5

This is an interesting discussion about long running tasks and threads.
Maybe the following considerations can help a little bit.
Task with thread pool disadvantages
- Thread pool creates new threads only at intervals. The interval is currently half a second.
Task LongRunning / thread disadvantages
- 1 MB virtual memory stack space for a thread
- Maximum 2'000 threads in a 32-bit process
- Task switching overhead
Additional thread features
- Priority
- Name
- ...

Answer 6

Hi Reed-

re: "it sounds like a Task flagged as LongRunning causes the Task to not use a ThreadPool thread?"

As a mental model, think of it as suggesting to the underlying scheduler that it increase the concurrency level, such that more threads than would otherwise be used are in fact used to process work items while this Task is running.  In practice, our actual implementation in .NET 4 does exactly what you say, using a non-ThreadPool thread to run the Task, but that's an implementation detail, and could change in the future.

re: "Is there a disadvantage of using a single long running task instead of a self-managed thread if I was going to make a thread that would exist for (nearly) the entire lifetime of the application?"

The one disadvantage is that you don't have access to control certain characteristics of the underlying thread that need to be set prior to the thread starting.  So, for example, if you needed a different thread stack size, or if you needed to set its apartment state, that's not avaialble through the Task abstraction.

An important thing to note, of course, is that what I've just described is the default TaskScheduler's behavior.  The default TaskScheduler implements LongRunning as I outlined above, but a custom scheduler could do whatever it wanted with the LongRunning hint.

Answer 7

Stephen,

Thank you!  Very helpful, as always.

-Reed

---

Reed Copsey, Jr. - http://reedcopsey.com