我的项目需要从多个来源收集数据，然后响应数据收集的完成而采取行动。一些收集任务依赖于先前的收集任务。 TPL 非常适合，因为它自然地继续执行前一个任务，并且使用结果的“最终”任务又是依赖的。伟大的。然而，我们希望有一个“睡眠和重新聚集”任务，该任务在完成“最终”任务后开始；从逻辑上讲，该任务的工作是“最终”任务的先决条件并开始下一个周期。实际上，TPL 的 DAG 变成了循环，或者，如果按顺序考虑，则成为循环。
是否可以在 TPL API 中完全表达这种循环要求？如果是这样，怎么办？我们当前的实现对前因执行 WaitAll() 操作，然后给定委托执行 Task.StartNew() 操作，该代理执行睡眠操作，然后使用以下命令重建任务图WaitAll()。这可行，但似乎有点人为。
My project has a requirement to gather data from a number of sources, then do things in response to the completion of the gathering of that data. Some of the gathering tasks have dependencies on prior gathering tasks. TPL has been a good fit because it naturally continues with tasks from their antecedents, and the "final" tasks that use the results are again dependents. Great. However, we would like to have a "sleep and regather" task that starts upon completion of the "final" tasks; this task's job is logically to be the antecedent of the "final" tasks and kick off the next cycle. In effect, the TPL's DAG becomes cyclic, or, if thought of sequentially, a loop.
Is it possible to express this cyclic requirement completely within the TPL API? If so, how? Our current implementation instead does a WaitAll() on the antecedents, and then a Task.StartNew() given a delegate that does a sleep followed by rebuilding a task graph with the WaitAll(). This works, but seems a bit artificial.
发布评论
评论（1）
这里有几个选项。你现在所做的事情看起来很合理。
但是，您可以使用
BlockingCollection将整个操作设置为生产者/消费者场景。如果您的消费枚举使用了在WaitAll完成后设置的ManualResetEvent，则它可以允许一次使用单个“项目”，并使用您拥有的任务现在写的。话虽这么说，这似乎是 TPL Dataflow 库的完美候选者（在CTP）。
There are a few options here. What you are doing now seems reasonable.
However, you could potentially setup the entire operation as a producer/consumer scenario using
BlockingCollection<T>. If your consuming enumerable used aManualResetEventthat was set after theWaitAllcompleted, it could allow a single "item" to be consumed at a time, using tasks as you have it written now.That being said, this seems like a perfect candidate for the TPL Dataflow library (in CTP).