.NET TPL lambdas 和闭包 - 此代码是否有效

Question

所以我正在尝试使用 .NET 4.0 中的 TPL 功能并编写一些类似这样的代码（不要笑）：

/// <summary>Fetches a thread along with its posts.  Increments the thread viewed counter.</summary>
public Thread ViewThread(int threadId)
{
   // Get the thread along with the posts
   Thread thread = this.Context.Threads.Include(t => t.Posts)
       .FirstOrDefault(t => t.ThreadID == threadId);

   // Increment viewed counter
   thread.NumViews++;
   Task.Factory.StartNew(() =>
   {
       try {
           this.Context.SaveChanges();
       }
       catch (Exception ex) {
           this.Logger.Error("Error viewing thread " + thread.Title, ex);
       }

       this.Logger.DebugFormat(@"Thread ""{0}"" viewed and incremented.", thread.Title);
   });

   return thread;
}

所以我对 lambda 的直接关注是 this.Context（我的实体框架数据上下文成员）、this.Logger（记录器成员）和线程（在记录器调用中使用）。通常在 QueueUserWorkItem() 天，我认为这些需要作为状态对象的一部分传递给委托。关闭会不会让我不再需要这样做？

另一个问题是该例程所在的类型实现了 IDisposable，因此位于 using 语句中。所以如果我做类似...

using (var bl = new ThreadBL()) {
            t = bl.ViewThread(threadId);
        }

...我要在 dispose() 调用和 TPL 开始调用我的 lambda 之间进行竞争吗？

目前我看到上下文将数据保存回我的数据库，但没有记录 - 也没有例外。这可能是我的配置问题，但这段代码感觉很奇怪。我不想在其他线程中有未处理的异常。欢迎任何意见！

Answer 1

至于你关于闭包的问题，​​是的，这正是闭包的意义所在。您不必担心传递状态，而是从任何外部上下文中为您捕获并复制到编译器提供的类中，该类也是定义闭包方法的地方。编译器在这里做了很多魔法，让你的生活变得简单。如果您想了解更多，我强烈建议您深入学习 Jon Skeet 的 C#。关于闭包的章节其实是available here。

至于您的具体实现，它主要不适用于您提到的确切问题：任务将安排在ViewThread 的末尾，但可能在您的ThreadBL 实例被处理之前不会执行。