PPL-创建无限数量的线程 [英] PPL - creation of unbounded number of threads

问题描述

我一直在产品中使用ppl(现在使用VS10)，并且看到过并发运行时创建1000个线程导致程序终止的情况.在使用ppl的实现中，我们使用默认的Scheduler和task_group.问题是 这是由于以下事实造成的:在某个地方我们使用了并发感知互斥体，因此并发运行时会旋转另一个线程来有希望地"执行与等待相同资源"无关的工作；作为其他任务.当然在某些情况下可能会发生 ppl产生线程将等待相同的资源.

我们在任务之间没有依赖性，所以我不希望线程数量激增.据我了解，Win8从内核模式开始进行了重大更改，以防止这种线程创建爆炸，但是我想知道哪种方法最好?

---

Ghita

解决方案

我也一直在研究这个问题.

在这里(至少对于我们的方案而言)有用的是使用UMS(用户模式计划).例如，可以通过将默认调度程序策略定义为

来启用此功能

并发性:: Scheduler :: SetDefaultSchedulerPolicy(Concurrency :: SchedulerPolicy(1，Concurrency :: SchedulerKind，Concurrency :: UmsThreadDefault));

但是它不能在您的XP/Vista应用程序中运行:

UMS可用于在Windows 7和Windows Server 2008 R2的64位版本上运行的64位应用程序. 或更高版本的Windows.此功能在32位版本的Windows上不可用.

可以在以下页面上找到有关UMS的更多信息:

http://msdn.microsoft. com/zh-CN/library/windows/desktop/dd627187(v = vs.85).aspx#ums_scheduler

http://msdn.microsoft.com/zh-cn/windowsserver2008r2trainingcourse_numaumscppconcurrency_topic3#_Toc277677420 >

http://msdn.microsoft.com/en-us/windowsserver2008r2trainingcourse_numaumscppconcurrency_topic12.aspx

http://blogs.msdn.com /b/nativeconcurrency/archive/2010/07/26/the-promise-of-ums.aspx

坏消息是，从Visual Studio 2012的并发运行时中删除了UMS.请参阅:

http://msdn.microsoft.com/en -us/library/bb531344.aspx

http://msdn.microsoft.com/en-us/library/dd492665(v=vs.110).aspx

并发中不支持用户模式可调度(UMS)线程在Visual Studio 2012中运行.使用  UmsThreadDefault 为 SchedulerType 的值 政策不会导致错误.但是，使用该策略创建的调度程序将默认使用Win32线程.

在这里，他们解释了原因:

Concrt中的UMS支持已被淘汰，因为尽管它在上下文切换方面非常快，结构化的并行程序不应进行大量上下文切换.在 换句话说，在大多数实际的PPL方案中，UMS调度程序并没有比常规Win32线程调度程序更快."

我认为这不是一个很好的理由.您可以使用并发运行时来实现基于角色的系统，例如，每个角色在逻辑上都有自己的控制线程.这是经过充分研究和确定性的编程模型，但在此 情况下会有很多上下文切换.

Hy,

I've been using ppl in a product (using VS10 for now), and I've seen cases where concurrency runtime is creating 1000 threads which leads to program termination. In our implementation using ppl we use the default scheduler and task_group. The problem is caused by the fact that in a place we use concurrency aware mutex so that concurrency runtime spins another thread for doing "hopefully" work that has nothing to do with "waiting on the same resource" as the other tasks. Of course in some cases it could happen that the ppl spawn threads would be waiting for the same resource.

We don't have dependency between tasks so I would not want this explosion of threads. As far as I understand Win8 had made significant changes starting from kernel mode to prevent this kind of thread creation explosion but I wonder what would be the best approach for our current product where we have to support XP/Vista and above.

---

Ghita

解决方案

I also have been looking into this.

What helps here (at least for our scenarios) is using UMS (User Mode Scheduling). You can enable this for example by defining the default scheduler policy as

Concurrency::Scheduler::SetDefaultSchedulerPolicy( Concurrency::SchedulerPolicy(1, Concurrency::SchedulerKind, Concurrency::UmsThreadDefault) );

It however won't work in your XP/Vista applications:

UMS is available for 64-bit applications running on 64-bit versions of Windows 7 and Windows Server 2008 R2 or later 64-bit versions of Windows. This feature is not available on 32-bit versions of Windows.

Some more information about UMS can be found on these pages:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd627187(v=vs.85).aspx#ums_scheduler

http://msdn.microsoft.com/en-us/windowsserver2008r2trainingcourse_numaumscppconcurrency_topic3#_Toc277677420

http://msdn.microsoft.com/en-us/windowsserver2008r2trainingcourse_numaumscppconcurrency_topic12.aspx

http://blogs.msdn.com/b/nativeconcurrency/archive/2010/07/26/the-promise-of-ums.aspx

The bad news is that UMS is removed from the Concurrency Runtime in Visual Studio 2012. See:

http://msdn.microsoft.com/en-us/library/bb531344.aspx

http://msdn.microsoft.com/en-us/library/dd492665(v=vs.110).aspx

User-mode schedulable (UMS) threads are not supported in the Concurrency Runtime in Visual Studio 2012. Using UmsThreadDefault as a value for the SchedulerType policy will not result in an error. However, a scheduler created with that policy will default to using Win32 threads.

Here they explain why:

http://social.msdn.microsoft.com/Forums/en-US/parallelcppnative/thread/afee813b-0dd9-498c-98c1-c996169099f6 "UMS support in Concrt is being retired because although it's super fast at context-switching, well-structured parallel programs shouldn't do a lot of context switching.  In other words, in most real PPL scenarios, the UMS scheduler wasn't any faster than the regular Win32 thread scheduler."

I don't think this is a good reason. You could use the concurrency runtime to implement for example an actor based system where every actor logically has it own thread of control. This is well studied and very deterministic programming model, but  in this case you'll have a lot of context switches.

这篇关于PPL-创建无限数量的线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！