问TPL与InvokeRequired/Invoke

EN

这看起来相当主观...

当你说“从.NET 4.0开始”时，你说的是“截至今年4月”- .net已经存在10年了，而InvokeRequired/Invoke在过去的9年里一直在使用。为什么MS会因为任何原因破坏所有现有的UI代码？即使存在一种调用线程的新方法，他们也不能简单地修改模式，而不会有巨大的兼容性问题。

此外，TPL并不类似于InvokeRequired/Invoke - TPL是关于简单的并行性，而invoke是关于在特定线程上运行代码。我不确定为什么一个会取代另一个，即使没有兼容性问题。

请注意，没有什么可以阻止您使用TPL来确保您在正确的线程上调用UI组件。事实上，您可以很容易地做到这一点。但这取决于您，当前的API不会以不向后兼容的方式进行更改。

有了TPL，你可以用TaskScheduler.FromCurrentSynchronizationContext指定目标线程，这个方法指定任务将在主线程上执行。我建议使用它而不是Invoke。

这里的问题是什么？TPL的存在并没有改变这样一个事实，即UI本质上是单线程的，并且要求只能在UI线程上访问控件。(这是.NET的限制，而不是Windows框架的限制。TPL不能改变Windows几十年来的设计限制。)

如果您的问题是关于混合使用InvokeRequired/Invoke的任务，那么有一种比Invoke更面向TPL的方法。TPL提供了一种内置的方法来调度在UI线程上运行的延续任务。因此，您将面向后台的工作放在一个任务中，然后将UI更新到另一个任务中。参见this post on task schedulers and SynchronizationContext。

(但实际上，TPL并不会取代任何旧的线程API。如果Invoke是做你想做的事情的最好方法，那就使用它。)