How to manage worker thread who wait until they have work to do?

I have a program that does the following:

1. Call webservice (there are many calls to the same web service)

2. Process the result of 1.

3. Insert result of 2. in a DB

So I think it should be better to do s开发者_开发问答ome multithreading. I think I can do it like this:

• one thread is the master (let's call it A)

• it creates some thread which calls the webservices (let's call it W)

• when W has some results it sends it to A (or A detects that W has some stuff)

• A sends the results to some computing thread (let's call it C)

• when C has some results it sends it to A (or A detects that C has some stuff)

• A sends the results to some database thread (let's call it D)

So sometimes C or D will wait for work to do.

With this technique I'll be able to set the thread number for each task.

Can you please tell me how I can do that, maybe if there is any pattern. EDIT : I added "some" instead of "a", so I'll create many thread for some time-consuming process, and maybe only one for the fastest.

It sounds to me like you could use the producer/consumer pattern. With .NET 4 this has become really simple to implement. Start a number of Tasks and use the BlockingCollection<T> as a buffer between the tasks. Check out this post for details.

In .net you have a thread pool.

When you release a thread it does not actually get closed, it just goes back into the thread pool. When you open a new thread you get one from the thread pool.

If they are not used for a long time the thread pool will close them.

I would start two timers, which will fire their event handlers on separate ThreadPool threads. The event handler for the first timer will check the web service for data, write it to a Queue<T> if it finds some, and then go back to sleep until the next interval.

The event handler for the second timer reads the queue and updates the database, then sleeps until its next interval. Both event handlers should wrap access to the queue a lock to manage concurrency.

Separate timers with independent intervals will let you decouple when data is available from how long it takes to insert it into the database, with the queue acting as a buffer. Since generic queues can grow dynamically, you get some breathing room even if the database is unavailable for a time. The second event handler could even spawn multiple threads to insert multiple records simultaneously or to mirrored databases. The event handlers can also post updates to a log file or user interface to help you monitor activity.