线程应该如何更新主程序中的全局数据？
我正在重新访问我的旧线程。
我想启动一堆线程，每个线程执行相同的任务，并在 main() 中知道每个线程何时完成以及它是否成功或失败。
提供的解决方案是使用 ConcurrentQueue，但其他帖子建议使用 BackgroundWorker 类，或者线程池。
有确定的答案吗？
同样，所有线程都执行相同的代码并具有通过/失败结果。我想运行比可用线程更多的线程，所以一旦一个线程完成，我就会尽快启动另一个线程 - 我希望技术尽可能地对远程系统施加压力（而不是用太多线程给我的本地 PC 施加压力，所以我会需要进行实验来确定最佳线程数）。
VB .NET 提供具体答案，但也欢迎一般线程建议。
I am revisiting an old thread of mine.
I want to launch a bunch of threads, each performing the same task, and know in main() when each finishs and it if it was successful or failed.
The solution offered was to use a ConcurrentQueue, but other posts have recommended using a BackgroundWorker Class, or a thread pool.
Is there a definitive answer?
Again, all threads perform the same code and have a pass/fail result. I want to run more than there are available threads so as soon as one thread finishes I will launch another asap - I want tehm to stress a remote systems as much as possible (reather than stressing my local PC with too many threads, so I will need to experiment to determine the optimal number of threads).
VB .NET for specific answer, but general threading advice is also welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
BackgroundWorker 是管理正在运行的线程的一种非常简单的方法。它允许您轻松地将进度报告回 UI。我认为没有明确的答案，但 BackgroundWorker 就是为此设计的目的 - 运行后台任务，随着进度更新 UI。下面是如何操作的示例。
BackgroundWorker is a very easy way to manage your running threads. It allows you to report progress back to the UI easily. I don't think there is a definitive answer but BackgroundWorker is designed for this purpose - running background tasks which update the UI as they progress. Here is an example of how to is it.
乔希的就是我要走的路。
根据需要创建尽可能多的新后台工作人员，连接以拦截其“完成”事件（我忘记了确切的名称），当这些事件在主应用程序线程上重新触发时，将结果存储在某种集合/列表/数组中。
如果您确实需要池化线程，那么事情会变得有趣，这样您就不会创建大量可能导致大量上下文抖动的线程。相反，您希望拥有一个池，例如 2x（机器中处理器的数量），并且当每个后台工作人员完成时，在其位置上排队另一个任务。
Josh's is the way I'd go.
Create as many new backgroundworkers as you need, hook up to intercept their "finished" event (I forget the exact name), and when those events fire back on the main app thread, store the results in a collection/list/array of somesort.
Things can get interesting if you really need to pool threads so you don't just create a ton of threads which can cause a lot of context thrashing. Instead, you want to have a pool of, say 2x(the number of processors in the machine), and as each backgroundworker finishes, queue up another task in it's place.
这取决于。在 Windows 窗体应用程序中，我会使用
BackgroundWorker，因为它非常易于设置和使用，而且它让我在寻找不正确的跨线程错误时省去了很多麻烦。但您必须注意，
BackgroundWorker仅在存在 UI 线程和消息循环的环境中才能正常工作。因此，例如，它不适用于控制台应用程序。在这种情况下，您应该使用其他解决方案，
Thread、ThreadPool或某种框架。It depends. In a Windows Forms application I would go with
BackgroundWorker, because it is very easy to setup and use and it saves me a lot of headache looking for incorrect cross-threading bugs.But you must be aware that
BackgroundWorkeronly works correctly in an environment where there is an UI thread and a message loop. So it will not work in console application, for instance.In that case you should use some other solution,
Thread,ThreadPoolor some kind of framework.我同意关于BackgroundWorker的主张。但是，如果您需要从后台线程访问 COM 对象，请不要使用BackgroundWorker，而是创建您自己的线程机制并根据需要使用 MTA STA 模型。
I agree with the propositions about BackgroundWorker. However, if you need to access COM objects from the background threads do not use the BackgroundWorker but create your own threading mechanismo and use MTA STA model as required.