My goal is to write a program that handles an arbitrary number of tasks based on given user input.
Let’s say the # of tasks are 1000 in this case.
Now, I’d like to be able to have a dynamic number of threads that are spawned and start handling the tasks one by one.
I would assume I need to use a “synchronous” method, as opposed to a “asynchronous” one, so that in case one tasks has a problem, I wouldn’t want it to slow down the completion of the rest.
What method would I use to accomplish the above? Semaphores? ThreadPools? And how do I make sure that a thread does not try to start a task that is already being handled by another thread? Would a “lock” handle this?
Code examples and/or links to sites that will point me in the right direction will be appreciated.
edit: The problem with the MSDN Fibonacci example is that the waitall method can only handle up to 64 waits. I need more than that due to the 1000 tasks. How to fix that situation without creating deadlocks?
Are these tasks independent? If so, you basically want a producer/consumer queue or a custom threadpool, which are effectively different views on the same thing. You need to be able to place tasks in a queue, and have multiple threads be able to read from that queue.
I have a custom threadpool in MiscUtil or there’s a simple (nongeneric due to age) producer/consumer queue in my threading tutorial (about half way down this page).
If these tasks are reasonably long-running, I wouldn’t use the system threadpool for this – it will spawn more threads than you probably want. If you’re using .NET 4.0 beta 1 you could use Parallel Extensions though.
I’m not quite sure about your comment on
WaitAll… are you trying to work out when everything’s finished? In the producer/consumer queue case, that would probably involve having some sort of “stop” entry in the queue (e.g. null references which the consuming threads would understand to mean “quit”) and then add a “WaitUntilEmpty” method (which should be fairly easy to implement). Note that you wouldn’t need to wait until the last items had been processed, as they’d all be stop signals… by the time the queue has emptied, all the real work items will definitely have been processed anyway.