none
Should I use Tasks for long running processes? RRS feed

  • Question

  • Hello all,

    I've been reading about threading lately and I've seen that the recommendation is that you create your own thread for long running processes instead of using the thread pool.  Then I started reading about tasks in .NET 4.  As they are built upon the thread pool, do the same rules apply to tasks that apply to the thread pool?  Should I still create my own thread for long running processes instead of using tasks?

    Thanks,
    Corey

    Wednesday, February 8, 2012 12:59 PM

Answers

  • Hi da.3vil.coder,

    You can specify that a task will be long-running by supplying TaskCreationOptions.LongRunning to the constructor of the task (or the Factory.StartNew method). What this actually does internally is generate a new thread outside of the threadpool to run the task on.

    var task3 = new Task(() => MyLongRunningMethod(),
                        TaskCreationOptions.LongRunning);
    task3.Start();
    

    See the link for more info: http://msdn.microsoft.com/en-us/library/dd537609.aspx

    Regards,

    Tyler

    • Marked as answer by da.3vil.coder Wednesday, February 8, 2012 2:47 PM
    Wednesday, February 8, 2012 2:25 PM
  • That is specifically talking about I/O threads - not all long-running tasks. Using a thread for a long-running task is not a bad idea, so long as those tasks are actually doing something the whole time. If your background process needs to do a lot of blocking calls (i.e. reading/writing to the hard disk, or calling web services synchronously), you shouldn't use ThreadPool. It has a limited number of threads available, and it can "starve" the process if you have several threads running but they're blocked.

    The best thing to do in those scenarios is just avoid blocking I/O. Use asynchronous calls with callbacks instead of taking up a process thread waiting for the blocking call. If that's not an option, you should create your own thread and give it a low priority rather than using the thread pool.

    If you just have a long-running process, but it works continously and isn't blocking, then you can still use the ThreadPool - though like Adavesh mentioned, this is usually an indication of a bad design. It's rare that you have a single contiguous long-running process which just takes a long time to complete, with no way to break it up and no way to parallelize any of it.

    EDIT: And I'm slow to come around to it, but in regards to your actual question - no, nothing has changed with the introduction of Tasks in 4.0. They still use the ThreadPool behind-the-scenes, so the same recommendations which applied to the thread pool before still apply to the task library now.


    Check out My Blog. Now updated to actually work!


    Wednesday, February 8, 2012 2:26 PM

All replies

  • Is it one task that takes long time? If yes, then you gain no benifit even by using Task (.NET 4). If you can devide that long running process into simple tasks and the create multiple threads to complete all these tasks parellelly (prpbably one thread per task). This can bring the execution time down to minimum.

    Please mark this post as answer if it solved your problem. Happy Programming!

    Wednesday, February 8, 2012 1:33 PM
  • Right, I understand that I should break things down and use mutliple thread but my question is do the rules that apply to using the thread pool's threads apply to using tasks since they are essentially thread pool threads or did something change in .NET 4 that changes all of this?

    When to use a dedicated thread (link)
    • When a foreground thread is required: All thread pool threads are initialised as background threads.
    • When it is required to have a thread with a particular priority.
    • When a thread is required to be aborted prematurely
    • When a thread must be placed in a single-threaded apartment (STA): All thread pool threads are set in the MTA apartment by default
    • For long running tasks when the thread pool thread is often blocked for long periods (This may starve other parts of the application which rely on threads from the thread pool)

    Wednesday, February 8, 2012 2:11 PM
  • Hi da.3vil.coder,

    You can specify that a task will be long-running by supplying TaskCreationOptions.LongRunning to the constructor of the task (or the Factory.StartNew method). What this actually does internally is generate a new thread outside of the threadpool to run the task on.

    var task3 = new Task(() => MyLongRunningMethod(),
                        TaskCreationOptions.LongRunning);
    task3.Start();
    

    See the link for more info: http://msdn.microsoft.com/en-us/library/dd537609.aspx

    Regards,

    Tyler

    • Marked as answer by da.3vil.coder Wednesday, February 8, 2012 2:47 PM
    Wednesday, February 8, 2012 2:25 PM
  • That is specifically talking about I/O threads - not all long-running tasks. Using a thread for a long-running task is not a bad idea, so long as those tasks are actually doing something the whole time. If your background process needs to do a lot of blocking calls (i.e. reading/writing to the hard disk, or calling web services synchronously), you shouldn't use ThreadPool. It has a limited number of threads available, and it can "starve" the process if you have several threads running but they're blocked.

    The best thing to do in those scenarios is just avoid blocking I/O. Use asynchronous calls with callbacks instead of taking up a process thread waiting for the blocking call. If that's not an option, you should create your own thread and give it a low priority rather than using the thread pool.

    If you just have a long-running process, but it works continously and isn't blocking, then you can still use the ThreadPool - though like Adavesh mentioned, this is usually an indication of a bad design. It's rare that you have a single contiguous long-running process which just takes a long time to complete, with no way to break it up and no way to parallelize any of it.

    EDIT: And I'm slow to come around to it, but in regards to your actual question - no, nothing has changed with the introduction of Tasks in 4.0. They still use the ThreadPool behind-the-scenes, so the same recommendations which applied to the thread pool before still apply to the task library now.


    Check out My Blog. Now updated to actually work!


    Wednesday, February 8, 2012 2:26 PM