使用 BlockingCollection 时从消费者任务向生产者任务发出信号
我有一个非常基本的应用程序，它使用生产者任务和消费者任务来处理文件。它基于此处的示例 http://msdn.microsoft.com/en- us/library/dd267312.aspx
该程序的基础知识是 Producer 任务枚举硬盘上的文件并计算它们的哈希值并执行一些其他操作。一旦生产者完成对文件的处理，它就会对文件进行排队，然后消费者会获取它。
消费者任务必须连接到远程服务器并尝试上传文件。但是，如果消费者遇到错误，例如无法连接到远程服务器，我需要它向生产者任务发出信号，指示它应该停止正在执行的操作并终止。如果服务器宕机或宕机，生产者无需继续循环处理数千个文件。
我已经看到了大量通过在 BlockingCollection 对象上使用 .CompleteAdding() 从 Producer 任务向 Consumer 任务发送信号的示例，但我不知道如何从 Consumer 向 Producer 发送应该停止生产的信号。
I have a pretty basic application that uses a Producer task and a Consumer task to work with files. It is based off the example here http://msdn.microsoft.com/en-us/library/dd267312.aspx
The basics of the program is that the Producer task enumerates the files on my hard drive and calculates their hash values and does a few other things. Once the Producer has finished working with a file, it Enques the file and the Consumer then grabs it.
The Consumer task has to connect to a remote server and attempt to upload the file. However, if the Consumer encounters an error, such as, not being able to connect to the remote server I need it to signal the Producer task that it should stop what it is doing and terminate. If the server is down, or goes down, there is no need for the Producer to continue cycling through thousands of files.
I have seen plenty of samples of signalling the Consumer task from the Producer task by using .CompleteAdding() on the BlockingCollection object but I am lost as to how to send a signal to the Producer from the Consumer that it should stop producing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以使用返回队列。如果其中一项生成错误/异常，您可以向其加载错误数据并将其排队返回生产者。生产者应该在生成新项目之前从返回队列中 TryTake() 并适当地处理任何返回的项目。这通过使项目能够使用扩展错误信息发回信号来击败使用一些原子布尔值，这些错误信息可用于决定采取什么操作 - 生产者可能并不总是希望/需要停止。此外，您还可以将出错的项目排队到 GUI 列表和/或记录器中。
人们很容易认为消费者无论如何都应该退货，无论商品是否有误，这样它们就可以重复使用，而不是一直创建新商品。但是，除非您使用两个返回队列来确定错误返回的优先级，否则这会在检测/处理错误时引入延迟。
哦 - 另一件事 - 使用上述设计，如果必须停止，生产者可以将错误的项目保留在本地队列中，并偶尔重新发布。如果服务器恢复正常（如返回成功的项目所示），生产者可以在生成更多新作业之前再次从本地队列重新发出错误作业。如果小心的话，这可以使您的上传系统能够适应服务器重新启动。
You could use a return queue. If one of the items generates an error/exception, you could load it up with error data and queue it back to the producer. The producer should TryTake() from the return queue just before generating a new item and handle any returned item appropriately. This beats using some atomic boolean by enabling the item to signal back with extended error information that could be used to decide what action to take - the producer may not always want/need to stop. Also, you could then queue up errored items to a GUI list and/or logger.
It's tempting to say that the consumer should return items anyway, whether they are errored or not, so that they can be re-used insted of creating new ones all the time. This, however, intruduces latency in detecting/acting on errors unless you use two return queues to prioritize error returns.
Oh - another thing - using the above design, if it has to stop, the producer could retain errored items in a local queue an re-issue one occasionally. If the server comes back up, (as indicated by the return of a successful item), the producer could re-issue the errored jobs from the local queue again before generating any more new ones. With care, this could make your upload system resilient to server reboots.