.net multi-threading
I'm writing dll which must run a function multiple times using different parameters, parallell to everything else.
I've tried the following methods:
- Backgroundworkers
- MethodInvoker
- Threads
- etc
What's the best way to do it?
Update:
I'm 开发者_运维知识库writing a dll, no GUI involved
If you're using .NET 4.0, you should make use of the new Parallel Task Library.
If not, consider using the threadpool to do your work with ThreadPool.QueueUserWorkItem()
. Failing that, creating a new Thread
object is the way to go. Do not use BackgroundWorker
for this; only if you were trying to decouple long-running processor-intensive code from blocking the UI would you use the BackgroundWorker
.
There's a pretty good example of waiting for all the user workitems to complete here: http://msdn.microsoft.com/en-us/library/z6w25xa6.aspx. Essentially you pass a ManualResetEvent
object into each call that is Set()
when the async code completes. You put all the ManualResetEvent
objects in an array and call WaitHandle.WaitAll()
passing in that array to wait for all the waithandles to be set.
Another technique could be to have a controlled number of Thread
objects running that are waiting for items to appear in a Queue
. This is a fairly standard Producer/Consumer pattern that means you need less threads (and therefore resources) but can still decouple the request from the work by putting messages on a queue. If you need the queue to be durable you could use MSMQ (and you can go even further than that with an ESB).
As you can see, where you are considering multi-threading makes a massive difference on how you implement it. Windows Form multithreading would not be the same as a Windows Service's multithreading, and in turn neither would be the same as in an ASP.NET web application (where arguably threading isn't even a good idea due to resource management in IIS). If you update your question we can be more specific to your current needs.
Threading is tricky - which is "best" depends on the very specific scenario. For example, on a web server "best" may be not to use threading at all, and let other threads handle other requests. One thing you should avoid is saturating the ThreadPool
, as other core parts of the system depend on that.
It sounds like a multiple-reader worker queue would serve your purposes; note also that .NET 4.0 introduces a range of controlls (around "Parallel" and "Tasks") that make threaded code easier to handle. A reasonable overview is here.
My suggestions:
- If you are starting a background thread from a WinForms UI, use the BackgroundWorker component.
- If you don't particularly care when the job starts or finishes as long as it runs, use an asynchronous delegate or the thread pool.
- Otherwise, create a new thread manually.
精彩评论