Introduction

Different kinds of Thread Pools are available: Smart Thread Pool, BlackHen.Threading, but nothing supports extensions. All Thread Pools are hard coded, and it's too difficult to work with any. I've tried to address these issues:

A Thread Pool should be extensible and configurable

A Thread Pool should be as simple as possible

So, I've created a Tiny Thread Pool. This Thread Pool is written using C# 4.0.

Tiny Thread Pool Features

Really simple

Extensible queues

Extensible Task Items

Limit on the maximum number of working threads

Dynamic thread workers

Task priority support

Extensible logging

Tiny Thread Pool Design

ITaskItem represents a task

ITaskQueue represents the task queue logic

ITaskQueueController represents the communication logic between the consumer and the producer (thread safe)

WorkThread represents a thread worker

TinyThreadPool controls work threads

Let's take a look at each class more deeply:

The ITaskItem represents some work that should be done.

publicinterface ITaskItem
{
void DoWork();
}

TaskItemPriority - WorkThread priority can be specified for each task.

The ITaskQueue is another simple interface that manages the task queue.

Bounded Task Queue Controller

BoundedTaskQueueController (thread safe) - if the producer task or tasks create items at a rate faster than the consumer can process them, the system can run into unbounded memory usage. The BoundedTaskQueueController allows you to place a limit on the size that the queue may reach before the producer is forced to block.

First, very nice work. I have a small suggestion to provide a means of queuing up work items without the need to implement the ITaskItem interface, which doesn't provide all that much functionality anyway. It also makes your implementation more C# 3.0-friendly, since lambdas are becoming all the rage these days .

First of all kudos to you on this. Looks nice at a glance. I have a need for managing a custom pool and I have been putting off implementing one until later in my project. I'm looking forward to digging into your implementation this weekend to evaluate if it meets my needs (or can be EXTENDED to do so ).

Given the topic of thread pools - thread safety is a must as you have pointed out. However, LOCK's are rather poor performers for high hardware thread count machines. The way technology is heading, even in the desktop world, this penalty is going to become a serious bottle neck. I suggest trading in the LOCK's for INTERLOCKS especially when it is known that scores of threads could be accessing a shared structure. Some interlock based data structures in C#: LockfreeQueue[^] There are also interlocked increment and decrement API's provided in the .NET framework.

Consider the following change.
Here i assume that the queue is implemented using interlocks where a dequeue on an empty queue results in a value of NULL. There is no overhead of locking and the code is actually simplified. I have not tested this code - consider it to be sudo code. The code in dispose should also be modified to release a 'significantly large enough' number of resources to ensure all threads will exit.

Also consider adding a finalizer that calls the destructor in your TaskQueueControllerBase class. This will ensure that the queue will be disposed of at some point even if the user forgets to call dispose. This is particularly useful when dealing with thread management. For example the main form for a program gets closed but dispose was never called - this can result in a process that remains running but has no UI and isn't doing anything useful.

~TaskQueueControllerBase()
{
Dispose();
}

I'm not trying to insult the code or the coder with this thread. In fact kudos again as the code will let me implement such a system as remarked above without any modification to the provided framework source! I'm trying to open a discussion on possible optimizations and arrive at a better understanding of how to efficiently manage parallel programming in my code as well. If anyone sees flaws in my above sudo code I'd love to discuss them too.

I mean that thread pools: Smart Thread Pool, BlackHen.Threading are hard coded and if I want to add different type of WorkQueue/TaskQueue or change thread communication logic I have to spend too many time for it.

"The Unity Application Block (Unity) is a lightweight, extensible dependency injection container with support for constructor, property, and method call injection. It provides developers with the following advantages:

It provides simplified object creation, especially for hierarchical object structures and dependencies, which simplifies application code.
It supports abstraction of requirements; this allows developers to specify dependencies at run time or in configuration and simplify management of crosscutting concerns.
It increases flexibility by deferring component configuration to the container.
It has a service location capability; this allows clients to store or cache the container. This is especially useful in ASP.NET Web applications where the developers can persist the container in the ASP.NET session or application." (c) MSDN

On the ExtendedThreadPool you can change all and you should not drop source code