4

使用 ThreadPool 采用以下简单的嵌套异步循环实现：

ThreadPool.SetMaxThreads(10, 10);
CountdownEvent icnt = new CountdownEvent(1);
for (int i = 0; i < 50; i++)
{
    icnt.AddCount();
    ThreadPool.QueueUserWorkItem((inum) =>
    {
        Console.WriteLine("i" + inum + " scheduled...");
        Thread.Sleep(10000);  // simulated i/o
        CountdownEvent jcnt = new CountdownEvent(1);
        for (int j = 0; j < 50; j++)
        {
            jcnt.AddCount();
            ThreadPool.QueueUserWorkItem((jnum) =>
            {
                Console.WriteLine("j" + jnum + " scheduled...");
                Thread.Sleep(20000);  // simulated i/o
                jcnt.Signal();
                Console.WriteLine("j" + jnum + " complete.");
            }, j);
        }
        jcnt.Signal();
        jcnt.Wait();
        icnt.Signal();
        Console.WriteLine("i" + inum + " complete.");
    }, i);
}
icnt.Signal();
icnt.Wait();

现在，您永远不会使用这种模式（它会在启动时死锁），但它确实演示了线程池可能导致的特定死锁 - 通过在阻塞线程消耗整个池后等待嵌套线程完成时阻塞。

我想知道使用嵌套的 Parallel.For 版本是否存在产生类似有害行为的潜在风险：

Parallel.For(1, 50, (i) =>
{
    Console.WriteLine("i" + i + " scheduled...");
    Thread.Sleep(10000);  // simulated i/o
    Parallel.For(1, 5, (j) =>
    {
        Thread.Sleep(20000);  // simulated i/o
        Console.WriteLine("j" + j + " complete.");
    });
    Console.WriteLine("i" + i + " complete.");
});

显然调度机制要复杂得多（而且我还没有看到这个版本出现死锁），但潜在的风险似乎仍然潜伏在那里。理论上是否有可能通过依赖嵌套线程来使 Parallel.For 使用的池干涸到造成死锁的程度？即对于延迟后安排的作业，Parallel.For 保留在其后袋中的线程数是否有限制？

4

1 回答 1

4

不，不存在像Parallel.For()（或Parallel.ForEach()）中那样的死锁风险。

有一些因素会降低死锁的风险（如使用的线程的动态计数）。但是死锁不可能的还有一个原因：迭代也是在原始线程上运行的。这意味着如果ThreadPool完全忙，计算将完全同步运行。在这种情况下，您不会从 using 中获得任何加速Parallel.For()，但您的代码仍将运行，不会出现死锁。

此外，与 s 类似的情况Task也得到了正确解决：如果您Wait()在尚未安排的Task（或访问它的）上，它将在当前线程中内联运行。Result我认为这主要是一种性能优化，但我认为它在某些特定情况下也可以避免死锁。

但我认为这个问题更多的是理论而不是实际。.Net 4ThreadPool的默认最大线程数设置为一千。而且，如果您同时有数千个Thread阻塞，那么您就做错了。

于 2012-06-30T00:42:01.590 回答