When to use TaskEx.Run vs. TaskEx.RunEx

后端 未结 3 1109
遥遥无期
遥遥无期 2021-02-06 03:00

I\'m trying to understand when to use TaskEx.Run. I have provided two code sample i wrote below that produce the same result. What i fail to see is why i would ta

相关标签:
3条回答
  • 2021-02-06 03:32

    The difference between your two DoWork() methods is that the first one (that uses TaskEx.RunEx()) is not asynchronous at all. It executes fully synchronously, starts the other task on another thread, and immediately returns a completed Task. If you awaited or Wait()ed on that task, it wouldn't wait until the internal task is completed.

    0 讨论(0)
  • 2021-02-06 03:54

    Use TaskEx.Run when you want to run synchronous code in a thread pool context.

    Use TaskEx.RunEx when you want to run asynchronous code in a thread pool context.

    Stephen Toub has two blog posts related to the difference in behavior:

    • Potential pitfalls to avoid when passing around async lambdas
    • Task.Run vs Task.Factory.StartNew

    This is only one of several options you have for creating tasks. If you do not have to use Run/RunEx, then you should not. Use simple async methods, and only use Run/RunEx if you need to run something in the background.

    0 讨论(0)
  • 2021-02-06 03:59

    Task.Run spawns a new thread in most scenarios as I understand it.

    It's important to note that simply because you mark a method as async, and use awaiters, this does NOT (necessarily) mean that new threads are being created, completions are scheduled on the SAME thread of execution that they were called from in many cases.

    The trick here has to do with the SchedulingContext. If it's set for a multithreaded apartment, then you're going to delegate completions to viable threads on the threadpool. If you're in a singlethreaded apartment as all WPF and WinForms UI code is, then it will return to the calling thread for completion allowing work to be done directly on the UI without visible thread marshalling in the code.

    0 讨论(0)
提交回复
热议问题