0

A user must query a large database for information repeatedly. This is done asynchronously. Only one query will be running at a time.

I did not create a new thread for each query as the code would be less clean, less maintable, etc.

I did not use ThreadPool.QueueUserWorkItem as this will tie up a ThreadPool thread for multiple seconds, and I'd rather not increase the minimum ThreadPool threads via ThreadPool.SetMinThreads as this won't be used by every user.

I solved this problem by creating my own single thread "ThreadPool" which just processes items. No new threads created, no ThreadPool thread occupied.

Should I have avoided the ThreadPool? Should I take a different approach?

Edit: I am limited to .net 3.5, and Visual Studio 2010.

William Morrison
  • 10,953
  • 2
  • 31
  • 48
  • 1
    This is precisely what `async`/`await` are for. Have you explored that? – Kirk Woll Feb 13 '14 at 02:39
  • Yes. I am limited to .net 3.5 and visual studio 2010. Is `Async/await` available for 3.5? I tried downloading a package to make async/awat available a few weeks ago with no success. – William Morrison Feb 13 '14 at 02:40
  • Can you show the code you have now. it will make it easier to create examples for you. – Scott Chamberlain Feb 13 '14 at 02:42
  • 1
    "Query large database..." and "threads are expensive" do not make a lot of sense together - processes that have 2-3 orders of magnitude difference (seconds for large DB operations vs. milliseconds for thread creation/overhead) are rarely lead to good comparison... And there is a good chance that you over-optimizing something that don't need to be optimized at all (most likely it would not make any difference if you use thread, thread pool, async or anything else to sequentially schedule DB operations). – Alexei Levenkov Feb 13 '14 at 02:43
  • I can tomorrow. It just does exactly as I've described. A single thread processes queries one at a time. – William Morrison Feb 13 '14 at 02:45
  • @Alexei had more to do with clean code, maintainability, and less importantly memory than CPU. Creating and joining a thread repeatedly is more complex to read than async or a separate dedicated threadpool. – William Morrison Feb 13 '14 at 02:47
  • 1
    Than you need to word your question differently... maybe even post to codereview.stackexchange.com instead. – Alexei Levenkov Feb 13 '14 at 02:48
  • Hmm... you might be right. I was worried this might be too opinion based... – William Morrison Feb 13 '14 at 02:50
  • You can refer to the this (http://stackoverflow.com/questions/230003/thread-vs-threadpool) for detailed explanation for ThreadPool usage, in your case Creating a Therad manually will be a preferred option. – Milan Raval Feb 13 '14 at 03:38

1 Answers1

1

I did not use ThreadPool.QueueUserWorkItem as this will tie up a ThreadPool thread for multiple seconds,

Only a (small) problem when the ThreadPool is very busy already. But even then 'squatting' a single thread isn't a real problem.

So no, do not create your own ThreadPool. That's adding a lot of complexity that solves nothing.

H H
  • 263,252
  • 30
  • 330
  • 514
  • I disagree. My code is a small part of a large project. What happens when another developer has the same thoughts, and only 2 threads are available on the thread pool? Very bad, everything using the thread pool has to wait now. I don't think C#'s Threadpool is meant for tasks like this. – William Morrison Feb 14 '14 at 03:01
  • Iirc the default MaxThreads was 50 in Fx 3 , in Fx4+ it's > 1000. You are imagining problems. – H H Feb 14 '14 at 08:14
  • Oh! I never thought to look up the default values. Just assumed the default max would be very low. Thanks, that solves my issues. Guess I should have used the threadpool. – William Morrison Feb 14 '14 at 13:44