Is Task.Factory.StartNew() guaranteed to use another thread than the calling thread?

by

I mailed Stephen Toub – a member of the PFX Team – about this question. He’s come back to me really quickly, with a lot of detail – so I’ll just copy and paste his text here. I haven’t quoted it all, as reading a large amount of quoted text ends up getting less comfortable than vanilla black-on-white, but really, this is Stephen – I don’t know this much stuff 🙂 I’ve made this answer community wiki to reflect that all the goodness below isn’t really my content:

If you call Wait() on a Task that’s completed, there won’t be any blocking (it’ll just throw an exception if the task completed with a TaskStatus other than RanToCompletion, or otherwise return as a nop). If you call Wait() on a Task that’s already executing, it must block as there’s nothing else it can reasonably do (when I say block, I’m including both true kernel-based waiting and spinning, as it’ll typically do a mixture of both). Similarly, if you call Wait() on a Task that has the Created or WaitingForActivation status, it’ll block until the task has completed. None of those is the interesting case being discussed.

The interesting case is when you call Wait() on a Task in the WaitingToRun state, meaning that it’s previously been queued to a TaskScheduler but that TaskScheduler hasn’t yet gotten around to actually running the Task’s delegate yet. In that case, the call to Wait will ask the scheduler whether it’s ok to run the Task then-and-there on the current thread, via a call to the scheduler’s TryExecuteTaskInline method. This is called inlining. The scheduler can choose to either inline the task via a call to base.TryExecuteTask, or it can return ‘false’ to indicate that it is not executing the task (often this is done with logic like…

return SomeSchedulerSpecificCondition() ? false : TryExecuteTask(task);

The reason TryExecuteTask returns a Boolean is that it handles the synchronization to ensure a given Task is only ever executed once). So, if a scheduler wants to completely prohibit inlining of the Task during Wait, it can just be implemented as return false; If a scheduler wants to always allow inlining whenever possible, it can just be implemented as:

return TryExecuteTask(task);

In the current implementation (both .NET 4 and .NET 4.5, and I don’t personally expect this to change), the default scheduler that targets the ThreadPool allows for inlining if the current thread is a ThreadPool thread and if that thread was the one to have previously queued the task.

Note that there isn’t arbitrary reentrancy here, in that the default scheduler won’t pump arbitrary threads when waiting for a task… it’ll only allow that task to be inlined, and of course any inlining that task in turn decides to do. Also note that Wait won’t even ask the scheduler in certain conditions, instead preferring to block. For example, if you pass in a cancelable CancellationToken, or if you pass in a non-infinite timeout, it won’t try to inline because it could take an arbitrarily long amount of time to inline the task’s execution, which is all or nothing, and that could end up significantly delaying the cancellation request or timeout. Overall, TPL tries to strike a decent balance here between wasting the thread that’s doing the Wait‘ing and reusing that thread for too much. This kind of inlining is really important for recursive divide-and-conquer problems (e.g. QuickSort) where you spawn multiple tasks and then wait for them all to complete. If such were done without inlining, you’d very quickly deadlock as you exhaust all threads in the pool and any future ones it wanted to give to you.

Separate from Wait, it’s also (remotely) possible that the Task.Factory.StartNew call could end up executing the task then and there, iff the scheduler being used chose to run the task synchronously as part of the QueueTask call. None of the schedulers built into .NET will ever do this, and I personally think it would be a bad design for scheduler, but it’s theoretically possible, e.g.:

protected override void QueueTask(Task task, bool wasPreviouslyQueued)
{
    return TryExecuteTask(task);
}

The overload of Task.Factory.StartNew that doesn’t accept a TaskScheduler uses the scheduler from the TaskFactory, which in the case of Task.Factory targets TaskScheduler.Current. This means if you call Task.Factory.StartNew from within a Task queued to this mythical RunSynchronouslyTaskScheduler, it would also queue to RunSynchronouslyTaskScheduler, resulting in the StartNew call executing the Task synchronously. If you’re at all concerned about this (e.g. you’re implementing a library and you don’t know where you’re going to be called from), you can explicitly pass TaskScheduler.Default to the StartNew call, use Task.Run (which always goes to TaskScheduler.Default), or use a TaskFactory created to target TaskScheduler.Default.

EDIT: Okay, it looks like I was completely wrong, and a thread which is currently waiting on a task can be hijacked. Here’s a simpler example of this happening:

using System;
using System.Threading;
using System.Threading.Tasks;

namespace ConsoleApplication1 {
    class Program {
        static void Main() {
            for (int i = 0; i < 10; i++)
            {
                Task.Factory.StartNew(Launch).Wait();
            }
        }

        static void Launch()
        {
            Console.WriteLine("Launch thread: {0}", 
                              Thread.CurrentThread.ManagedThreadId);
            Task.Factory.StartNew(Nested).Wait();
        }

        static void Nested()
        {
            Console.WriteLine("Nested thread: {0}", 
                              Thread.CurrentThread.ManagedThreadId);
        }
    }
}

Sample output:

Launch thread: 3
Nested thread: 3
Launch thread: 3
Nested thread: 3
Launch thread: 3
Nested thread: 3
Launch thread: 3
Nested thread: 3
Launch thread: 4
Nested thread: 4
Launch thread: 4
Nested thread: 4
Launch thread: 4
Nested thread: 4
Launch thread: 4
Nested thread: 4
Launch thread: 4
Nested thread: 4
Launch thread: 4
Nested thread: 4

As you can see, there are lots of times when the waiting thread is reused to execute the new task. This can happen even if the thread has acquired a lock. Nasty re-entrancy. I am suitably shocked and worried 🙁

More Related Contents:

  1. Why is lock(this) {…} bad?
  2. Task vs Thread differences [duplicate]
  3. When to use BlockingCollection and when ConcurrentBag instead of List?
  4. Is it considered acceptable to not call Dispose() on a TPL Task object?
  5. Starting Tasks In foreach Loop Uses Value of Last Item [duplicate]
  6. Re-entrant locks in C#
  7. Multiple Parallel.ForEach loops in .Net
  8. Proper way to implement a never ending task. (Timers vs Task)
  9. A Task’s exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was
  10. How to put a task to sleep (or delay) in C# 4.0?
  11. Task continuation on UI thread
  12. What is the use for Task.FromResult in C#
  13. The current SynchronizationContext may not be used as a TaskScheduler
  14. Is it OK to use a string as a lock object?
  15. How expensive is the lock statement?
  16. Monitor vs lock
  17. Process queue with multithreading or tasks
  18. Throw a NullReferenceException while calling the set_item method of a Dictionary object in a multi-threading scenario
  19. How to achieve remove_if functionality in .NET ConcurrentDictionary
  20. Why does the lock object have to be static?
  21. Calling async methods from non-async code
  22. When is ReaderWriterLockSlim better than a simple lock?
  23. Why CancellationToken is separate from CancellationTokenSource?
  24. Should i use ThreadPools or Task Parallel Library for IO-bound operations
  25. Cross-Process Locking in C#
  26. Faulted vs Canceled task status after CancellationToken.ThrowIfCancellationRequested
  27. Synchronous implementation of interface that returns Task
  28. Why is it a bad practice to lock the object we are going to change?
  29. Task chaining (wait for the previous task to completed)
  30. Wrapping ManualResetEvent as awaitable task

Leave a Comment