and no, i wouldn’t say you’re overly paranoid… when it comes to threading it’s probably best to be paranoid

well, the tasks are queued in a single thread, so the fact that QueueTask doesn’t lock queueMonitor is not that big of a problem, as long as this class is used ‘correctly’

Famous last words!

The problem (IMHO) is you don’t “know” how Queue is implemented. Sure you could go dig through with reflector but it was probably not written with multiple threads accessing it at the same time. So you lock queueMonitor and call Count, but if the other thread is calling QueueTask, it might allocate memory for the underlying array (assuming an array is being used) BEFORE the call to Count. If the memory gets published BEFORE the actual element is put into the array, then Count returns 1 and Queue.Dequeue could return a null reference as well as reallocate the array that just got allocated. Back in the QueueTask thread, you are now accessing an element in an array that doesn’t exist.

I’m probably being overly paranoid, but consider the following code…

for(int i = 0; i < m_RemainingWork; ++i)

The above code caused a very subtle race condition because some other code was calling Interlocked.Decrement(ref m_RemainingWork). The dev thought that the original for loop would completely execute before any of the background threads reduced m_RemainingWork. And on his Vista box, that is exactly what happened. On my 2008 server box (which treats all threads as equals), it blew up every time.

And one other observation, your ProcessTasks is going to take up quite a bit of CPU because it is basically a SpinLock waiting on work. There is no niceness there. The threads will continually look for work without every taking a break. Not sure about your use cases, so maybe there is a steady stream of work coming in and that doesn’t happen.

And yes, I mean pass the wait handle as the state. The lambda is redundant. You’ll have to cast instead (from object to WaitHandle). I love lambdas (I wrote a whole logging library using them – http://www.codeplex.com/LiveLabsLogging), but I generally don’t use them if I don’t have to. But that’s just my opinion.

but what state do you think i should pass to the constructor of the Thread? Do you mean getting rid of the lambda, and passing the WaitHandle as the state object reference?

And yes, Parallel Framework for .NET is on my TODO list :p
And yes, i will wait until the final release :p

Oh yeah…if you haven’t already check out the Parallel Framework for .NET. It has a nice Task management system complete with Futures. Although it would definitely break your “don’t touch till released rule”