我是否需要使用try catch或检查ThreadPool.QueueUserWorkItem

时间:2015-12-12 13:16:23

标签: c# .net multithreading threadpool

ThreadPool.QueueUserWorkItem

上述方法的文档说明了其返回类型:

  

如果方法成功排队,则为true;如果工作项无法排队,则抛出NotSupportedException。

这是否意味着该函数永远不会返回false?但反而投掷?如果是这样,那么为什么要有返回类型呢?我会说,或者返回true / false,无论WorkItem是否已排队,或者当WorkItem无法排队时返回true和throw类型。

我知道有这个duplicate question,但在我看来,它确实没有明确的答案。

2 个答案:

答案 0 :(得分:4)

您需要仔细阅读文档。虽然MSDN声明:

  

如果方法成功排队,则为true; NotSupportedException是   如果工作项无法排队,则抛出。

...只是吼叫也说:

  

NotSupportedException:托管公共语言运行时(CLR),   并且主持人不支持此操作。

我的意思是,如果托管环境不支持线程池,则会抛出NotSupportedException

因此,如果您将中的线程排队,则不需要try/catch块。至少,您可以使用常规布尔返回值检查线程是否可以排队。

答案 1 :(得分:1)

  

这是否意味着该函数永远不会返回false?但抛出   代替?如果是这样,那么为什么要有一个返回类型

Lets look at the source code

//ThreadPool has per-appdomain managed queue of work-items. The VM is
//responsible for just scheduling threads into appdomains. After that
//work-items are dispatched from the managed queue.
[System.Security.SecurityCritical]  // auto-generated
private static bool QueueUserWorkItemHelper(
    WaitCallback callBack, Object state, ref StackCrawlMark stackMark, bool compressStack)
{
    bool success =  true;

    if (callBack != null)
    {
        //The thread pool maintains a per-appdomain managed work queue.
        //New thread pool entries are added in the managed queue.
        //The VM is responsible for the actual growing/shrinking of 
        //threads. 

        EnsureVMInitialized();

        // If we are able to create the workitem, 
        // we need to get it in the queue without being interrupted
        // by a ThreadAbortException.
        //
        try { }
        finally
        {
            QueueUserWorkItemCallback tpcallBack = new QueueUserWorkItemCallback(
                                        callBack, state, compressStack, ref stackMark);
            ThreadPoolGlobals.workQueue.Enqueue(tpcallBack, true);
            success = true;
        }
    }
    else
    {
        throw new ArgumentNullException("WaitCallback");
    }
    return success;
}

似乎成功将真正返回true,因为它在排队项目之前最初设置,或者在运行时无法排队委托时抛出异常。

  

有更好的想法吗?

这对我来说似乎是多余的,除非你不真正信任运行时环境并且不确定它是否提供了底层的线程池机制。否则,如果你正在使用微软的运行时,你应该只使用原来的QueueUserWorkItem