5

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 while(true) { if(ThreadCount < MaxThreads) { new Thread(() => Process()).Start(); ThreadCount++; } else { Thread.Sleep(10000); } } private void Process() { //call ws //update records ThreadCount--; }
Improve this question
2
  • what you describe sounds like a thread pool - search the web for more details on that if you're interested Commented Jul 16, 2012 at 8:30
  • 1
    This kind of seems like the "database as message queue" anti pattern. en.wikipedia.org/wiki/Database-as-IPC Commented Jul 16, 2012 at 13:54

2 Answers 2

Reset to default
5

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.

Improve this answer
2
  • 1
    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? Commented Jul 17, 2012 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. Commented Jul 17, 2012 at 11:16
5

.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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.