为什么taskFactory.startNew方法不是泛型方法?

好吧,现在我已经完全理解了这个问题。)

我相信这是因为这是一个 direct replacement for ThreadPool.QueueUserWorkItem . 我同意这有点奇怪…但是 如果 无论如何,您使用的是lambda表达式,使用 做 取一个状态参数(即 Action 而不是 Action<object> )只需事先捕捉你感兴趣的价值。如果您分别指定值和函数,则没有帮助:(

根据StephenToub(MSFT)的一篇文章,他们假设我们将依靠闭包来传递状态数据。还有一些关于签名模糊的借口。( http://social.msdn.microsoft.com/Forums/en/parallelextensions/thread/1988294c-de41-476a-a104-aa550b7409f5 )

然而,依赖闭包来解决这个问题似乎是一个暂时的黑客等待更好的解决方案。它是有效的,但它不是一个好的长期解决方案。很多时候,简单地将委托方法指定为操作是最简单的方法,但这意味着我们必须使用全局变量,否则我们将被排除在状态参数传递之外。

我喜欢雨果的一个建议(来自微软论坛的帖子)。雨果建议引入一个taskstate类型,这似乎是一个巧妙的方法来规避泛型的歧义问题。

将此应用于task.factory.startNew()签名和task()构造函数,如下所示:

  public Task<T>( Action<T> function, TaskState<T> state );
  public Task<T,TResult>( Func<T,TResult> function, TaskState<T> state );

actionstate非常类似于nullable类——只是一个值成员周围的简单包装器。实际上,使用taskstate可能如下所示:

  var myTask = new Task( MyMethod, new TaskState( stateInfo ) );
  ...

  public void MyMethod( StateInfo stateInfo ) { ... }

taskstate解决方案并不完美,但似乎比依赖类型转换的闭包更好。