在控制台应用程序使用.NET BackgroundWorker的类 [英] Using .NET BackgroundWorker class in console app
问题描述
我是比较新的.NET编程和多线程在一般情况下，并想知道如果它是确定使用.NET提供BackgroundWorker的产卵关闭工作线程做一个控制台应用程序的一些工作？从各种在线文档，我看到的意图该类的多为面向用户界面的应用程序，在那里你想在后台的一些工作，但保留了用户界面反应灵敏，报告进度，取消加工如果需要等。
I am relatively new to .NET programming and multithreading in general, and was wondering if it is ok to use .NET provided BackgroundWorker to spawn off worker threads to do some work in a console application? From the various documentation online, I see that intent for this class is more for UI oriented applications, where you want to do some work in background, but keep the UI responsive, and report progress, cancelling processing if needed etc.
在我的情况下，基本上我有我想要的产卵关闭多个工作线程做一些处理（限制工作线程的最大数量人丁使用信号灯）控制器类。然后我想我的控制器类阻塞，直到所有的线程完成处理。所以，当我开始工作线程做一些工作，我想线程能够通知控制器线程时，处理完成。我看到，我可以使用的后台工作类，处理事件的DoWork和RunWorkerCompleted做到这一点，但是在想，如果这是个好主意吗？有没有更好的方式来实现这一目标？
In my case, basically I have a controller class where I want to spawn off multiple worker threads to do some processing (limiting the max number of worker threads spawned using a semaphore). Then I want my controller class to block until all the threads have completed processing. So after I start a worker thread to do some work, I want the thread to be able to notify the controller thread when processing is complete. I see that I can use the background worker class, and handle events DoWork and RunWorkerCompleted to accomplish this, however was wondering if this is good idea? Are there better ways to achieve this?
推荐答案
这不会在控制台应用程序的工作，因为的 SynchronizationContext.Current 的将永远不会被初始化。这是由Windows窗体或WPF为你初始化，当你使用一个GUI应用程序。
This won't work in a Console Application, since SynchronizationContext.Current will never be initialized. This is initialized by Windows Forms or WPF for you, when you're using a GUI application.
话虽这么说，没有理由这样做。只要使用 ThreadPool.QueueUserWorkItem 和复位事件（ ManualResetEvent的或的的AutoResetEvent ）套住完成状态，并阻止你的主线程。
That being said, there's no reason to do this. Just use ThreadPool.QueueUserWorkItem, and a reset event (ManualResetEvent or AutoResetEvent) to trap the completion state, and block your main thread.
编辑：
看到一些OP的意见后，我想我要补充这一点。
After seeing some of the OP comments, I thought I'd add this.
在最好的选择，在我看来，将获得的接收框架，因为它包含了第三方物流的.NET 4的反向移植这将允许您使用的 Parallel.ForEach 它提供了供给<一个选项href="http://msdn.microsoft.com/en-us/library/system.threading.tasks.paralleloptions%28VS.100%29.aspx"相对=nofollow> ParallelOptions 实例。这将允许你限制并发操作的总数，并处理所有的工作适合你：
The "nicest" alternative, in my opinion, would be to get a copy of the Rx Framework, since it includes a backport of the TPL in .NET 4. This would allow you to use the overload of Parallel.ForEach which provides the option of supplying a ParallelOptions instance. This will allow you to restrict the total number of concurrent operations, and handle all of the work for you:
// using collection of work items, such as: List<Action<object>> workItems;
var options = new ParallelOptions();
options.MaxDegreeOfParallelism = 10; // Restrict to 10 threads, not recommended!
// Perform all actions in the list, in parallel
Parallel.ForEach(workItems, options, item => { item(null); });
然而，使用Parallel.ForEach，我会亲自让系统管理并行度。它会自动分配线程（特别是当/如果这个移动到.NET 4）。
However, using Parallel.ForEach, I'd personally let the system manage the degree of parallelism. It will automatically assign an appropriate number of threads (especially when/if this moves to .NET 4).
这篇关于在控制台应用程序使用.NET BackgroundWorker的类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
