Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently planning a Windows service. It will be a multi-threaded application which will continuously check for database records and process them. My first thoughts were to set a number of max available threads and create new thread for each process. This works OK but since I'm creating a new thread for every new process I fear that its overhead will multiply if there are lots of records to process. My question is, is this a good design or would you recommend any other solutions?

Here's what the application will do basically:

  1. Check for available number of threads
  2. If there are available threads check the database for records to process.
  3. If there are records to process select top 100 of them
  4. Create a new process
  5. Call a web service for each record and update the record according to web service call result (This call+update usually take around 500ms so process will be live for about 50 seconds)
  6. Continue to step 1

This is currently what I am doing:

timer1.Tick += Tick();

private void Tick()
    //do some text logging
    //do some TextBox updating

int MaxThreads = 10

    if(ThreadCount < MaxThreads)
        new Thread(() => Process()).Start();

private void Process()
    //call ws
    //update records

share|improve this question
what you describe sounds like a thread pool - search the web for more details on that if you're interested –  gnat Jul 16 '12 at 8:30
This kind of seems like the "database as message queue" anti pattern. en.wikipedia.org/wiki/Database-as-IPC –  Kyle Hodgson Jul 16 '12 at 13:54

2 Answers 2

You should have a look at the thread pool pattern in Wikipedia, I think this is what you are looking for. The trick is to create n threads once when your service starts, avoiding the overhead of thread creation (see this question on SO) during runtime.

As for your workflow, you may want to consider switching the first two steps:
First check if there are records to process, and if there are, see if your thread pool has a free thread. This is an optimisation problem, you want to reach the decision no processing (because there is no data, or no resources for it) with as little effort as possible. If you reach this decision more often because there is no data to process, check for this first.

Some will argue that this is premature optimisation, but I personally prefer to err a little more on the premature side.

share|improve this answer
Wouldn't it be better to check if there are any available threads first? This way I would skip hitting database if there are no threads available. Am I missing a point? –  dstr Jul 17 '12 at 10:16
It depends on which is more likely: Your thread pool running out of threads, or there being no entries in the db waiting to be processed. If in 99.999 of the cases there is nothing in the db, you end up checking your thread pool 99.999 times for nothing, but you are checking the db every single one of the 100.000 times, too (because there are always threads available)! On the other hand, if you have data to process in 99.999 out of 100.000 times, then you should first check for available threads. My point, which I could have stated more clearly, is that Thou Shalt Not Assume. –  Treb Jul 17 '12 at 11:16

.Net has a built in thread pool that you can use to do work. But even better check the Task Parallel Library in .Net 4. This makes the most common scenarios for multithreading very simple to implement. Like using Parallel.For to process in parallel. Using Task to start a work in background and waiting for all of them to finish is another approach.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.