线程、队列和工作流答案

【问题标题】：Threads, queue and workflow线程、队列和工作流
【发布时间】：2010-08-27 14:09:15
【问题描述】：

（作为理由 - 我从未使用过线程，所以下面的描述只是我希望你批评的一个想法）

任务概述：
- 有一些对象的列表
- 我们需要检查对象是否以某种方式更改
- 如果已更改 - 应用一些逻辑（例如 - 显示通知）。

这就是我认为应该实现的方式：

我们创建计时器，每分钟触发一次，它遍历对象列表并找到需要检查的对象。之后，我们将该对象（或者更具体一点 - 一些任务对象，包含对象和任务描述：以检查它是否已更新）添加到队列中。

Worker（线程池中的某个线程）一直等待，直到将某些内容添加到队列中，并且在它发生之后 - 它接受 Task 并对其进行处理：检查 Object 是否已更改。如果是这样 - 它会添加另一个任务，通知一个。现在，如果需要，另一个处理通知任务的工作人员将处理此任务。

那么，这是完全错误的想法吗？这里有什么可以改进或改变的？

UPD：根据第一个答案：对象依赖于某个repot资源，而“更改”意味着某些远程数据已更改（或以某种特定方式更改）。所以这不能用INotifyPropertyChanged解决。

【问题讨论】：

【解决方案1】：

如果这些“对象”是 .NET 对象，为什么还要轮询它们？为什么不实现类似INotifyPropertyChanged 接口的东西，并获得适当的、即时的更改通知？

否则，如果它们实际上是某种类型的外部对象，只能通过轮询进行测试，那么一个计时器会触发一个事件，然后轮询每个对象并将通知调用回UI 线程可能就足够了，或者如果您希望计时器事件快速完成（例如，它可以立即响应另一个事件），请触发 Task 以检查每个对象并通知 UI（使用调用）如果它变了。

不需要将每个单独的对象排队并单独处理它们（有吗？？），也不需要并行处理它们，因此在工作线程（或Task）中对它们进行简单循环似乎充足的。

【讨论】：

有 - 因为“检查”操作可能是“长”的，因为 Object 与一些远程 3rd 方资源有关。
“也没有任何并行处理它们的要求，所以在工作线程中对它们进行简单的循环”——在这种情况下，关于何时工作和做什么工作的所有逻辑都在一个地方.有问题的是，我已经描述了它们完全被队列分开的场景：一部分是做出更新的决定，另一部分是做出处理的决定，然后在它们之间排队。
我会说这个答案或多或少是正确的——在对象上循环，触发一个任务去轮询每个对象，然后向 UI 线程报告。这样您就不必担心管理轮询线程等。
（哦，那我不明白，糟糕的英语）好吧，那么这个答案很简单：循环收集并为每个需要检查的对象启动线程？
您可以采取任何一种方式——为每个对象触发一个任务（如果您想并行处理它们）或触发一个按顺序处理它们的任务。由于您每分钟只轮询一次，我无法想象您为什么突然想要并行处理它们，但这就是为什么我实际上建议在任务中运行一个简单的循环。至于将轮询步骤与通知步骤分开，这似乎不必要地复杂 - 您有一个线程，如果它是您接下来要执行的纯顺序操作，请继续执行。

【解决方案2】：

我只是想知道您是否可以考虑为待处理任务设置队列。因此，任何推送到此队列的任务对象都在等待处理。在您的工作线程中，您会阻塞队列，直到有项目可用。如果您想要一些并行性，您可能有多个工作线程来执行此操作。

您可能还有一个任务列表显示哪些正在进行中，另一个列表显示哪些已完成。

我不是 C# 程序员，但在 Java 中，我希望使用 BlockingQueue 接口的实现。

【讨论】：