.NET中的通用ThreadPool

Cri*_*scu 5 .net c# generics multithreading threadpool

对于我来说,这是一个相对常见的任务,我认为,对于许多.NET程序员来说:
我想使用.NET ThreadPool来调度需要处理给定类型任务的工作线程.

作为回顾,ThreadPool及其关联委托的排队方法的签名是:

public static bool QueueUserWorkItem (
    WaitCallback callBack,
    Object state
)
public delegate void WaitCallback (Object state)
Run Code Online (Sandbox Code Playgroud)

因此,典型的通用工作线程类看起来像:

public class Worker<T> {
    public void schedule(T i_task) {
        ThreadPool.QueueUserWorkItem(execute, i_task)
    }
    private void execute(Object o){
        T task = (T)o;  //What happened to the type safety?  
        executeTask(task);
    }
    private void executeTask(T i_task){
        //process i_task
    }
}
Run Code Online (Sandbox Code Playgroud)

注意state参数的类型?是的Object!

.NET团队选择不使QueueUserWorkItem方法(或整个ThreadPool类)通用的令人信服的原因是什么?我无法相信他们只是忽略了它.

这是我想看到它的方式:

//in the ThreadPool class:
public static bool QueueUserWorkItem<T> (
    WaitCallback<T> callBack,
    T state
)
public delegate void WaitCallback<T> (T state)
Run Code Online (Sandbox Code Playgroud)

这将使工人类类型安全(并且更清晰,恕我直言):

public class Worker<T> {
    public void schedule(T i_task) {
        ThreadPool.QueueUserWorkItem<T>(execute, i_task)
    }
    private void execute(T i_task){
        //process i_task
    }
}
Run Code Online (Sandbox Code Playgroud)

我肯定错过了什么.

Bar*_*lly 7

因为通过将匿名委托或lambda传递给线程池(通过变量捕获)来打包你喜欢的任何状态是微不足道的,所以不需要通用版本.

例如,您可以编写一个实用程序函数:

static void QueueItem<T>(Action<T> action, T state)
{
    ThreadPool.QueueUserWorkItem(delegate { action(state); });
}
Run Code Online (Sandbox Code Playgroud)

但它不会非常有用,因为只要您在池化任务中需要状态,您就可以自己使用代理.


Mar*_*ell 5

听起来你在谈论工作队列?(我听起来很像......)

对于记录,线程池线程通常应该用于简短的工作.理想情况下,您应该为长期存在的队列创建自己的线程.请注意,.NET 4.0可能正在采用CCR/TPL库,因此我们将免费获得一些内置的工作队列 - 但编写一个线程化的工作队列并不难.你也可以把它变成通用的;-p

重的问题-我更喜欢捕捉变量的方法来穿过状态成线(是他们Thread,ThreadPoolControl.Invoke):

    Thread t = new Thread(() => SomeMethod(arg));
    t.IsBackground = true;
    t.Name = "Worker n";
    t.Start();
Run Code Online (Sandbox Code Playgroud)

这使您可以更精细地控制线程,而不会使线程饱和ThreadPool.

  • 我不明白你不使用线程池作为工作队列的底层"执行"层的论点.由于线程数量有限,使用**.NET ThreadPool类时这是一个问题吗?IMO很自然地假设工作队列中的任务很短.你能详细说明吗? (2认同)