对于我来说,这是一个相对常见的任务,我认为,对于许多.NET程序员来说:
我想使用.NET ThreadPool来调度需要处理给定类型任务的工作线程.
作为回顾,ThreadPool及其关联委托的排队方法的签名是:
public static bool QueueUserWorkItem ( WaitCallback callBack, Object state ) public delegate void WaitCallback (Object state)
因此,典型的通用工作线程类看起来像:
public class Worker{ 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 } }
注意state
参数的类型?是的Object
!
.NET团队选择不使QueueUserWorkItem
方法(或整个ThreadPool
类)通用的令人信服的原因是什么?我无法相信他们只是忽略了它.
这是我想看到它的方式:
//in the ThreadPool class: public static bool QueueUserWorkItem( WaitCallback callBack, T state ) public delegate void WaitCallback (T state)
这将使工人类类型安全(并且更清晰,恕我直言):
public class Worker{ public void schedule(T i_task) { ThreadPool.QueueUserWorkItem (execute, i_task) } private void execute(T i_task){ //process i_task } }
我肯定错过了什么.
因为通过将匿名委托或lambda传递给线程池(通过变量捕获)来打包你喜欢的任何状态是微不足道的,所以不需要通用版本.
例如,您可以编写一个实用程序函数:
static void QueueItem(Action action, T state) { ThreadPool.QueueUserWorkItem(delegate { action(state); }); }
但它不会非常有用,因为只要您在池化任务中需要状态,您就可以自己使用代理.
听起来你在谈论工作队列?(我听起来很像......)
对于记录,线程池线程通常应该用于简短的工作.理想情况下,您应该为长期存在的队列创建自己的线程.请注意,.NET 4.0可能正在采用CCR/TPL库,因此我们将免费获得一些内置的工作队列 - 但编写一个线程化的工作队列并不难.你也可以把它变成通用的;-p
重的问题-我更喜欢捕捉变量的方法来穿过状态成线(是他们Thread
,ThreadPool
或Control.Invoke
):
Thread t = new Thread(() => SomeMethod(arg)); t.IsBackground = true; t.Name = "Worker n"; t.Start();
这使您可以更精细地控制线程,而不会使线程饱和ThreadPool
.