我创建了大约5000个后台工作人员，他们在控制台应用程序中做密集的工作。我还使用了一个实例化对象的外部库，比如ObjectX。在某个时刻，比如在0点，ObjectX尝试从os线程池获取一个线程并启动它，但是我无法控制它如何获取这个线程。100个后台工作人员工作得很好。对于1000个后台工作线程，ObjectX在0之后大约需要10分钟来获取并启动一个线程。
-
是否有一种方法可以预先为将来由对象启动的任何线程设置高优先级?
-
我认为第一个问题的答案是"不"，有没有一种方法可以限制后台工作人员的优先级，从而以某种方式支持其他一切?尽管我只想"支持"ObjectX.
目标是始终有可用的资源来运行ObjectX启动的线程，无论机器有多超载。
我在Windows 64位机器上使用c#和。net 3.5。
线程的工作方式是由操作系统给它们处理器时间。当这种情况发生时，这被称为上下文切换。上下文切换大约需要2000-8000个周期(即取决于处理器2000-8000条指令)。如果操作系统有许多CPU或内核，它可能不需要将CPU从一个线程中取出并将其提供给另一个线程——避免上下文切换。每个CPU一次只能运行一个线程，当需要CPU的线程多于CPU时，就会强制进行上下文切换。上下文切换的执行速度不会快于系统量子(客户端每20ms一次，服务器每120ms一次)。
如果你有5000个后台工作者，你实际上有5000个线程。这些线程中的每一个都可能在争夺CPU时间。在客户端版本的windows上，这意味着每秒250,000个上下文切换。例如，每秒500,000,000到200,000,000个周期用于在线程之间切换。(即超过线程正在执行的工作)，如果它甚至可以每秒处理那么多上下文切换。
建议的做法是每个处理器只有一个cpu绑定线程。cpu绑定线程是花费很少时间"等待"的线程。UI线程不是cpu绑定线程。如果后台工作线程花费大量时间等待锁，那么它们可能也不是cpu绑定的——但是，一般来说，后台工作线程是cpu绑定的。(否则，使用后台工作线程有什么意义呢?)。
同时，操作系统花了很多时间来确定下一个线程需要得到CPU。当你开始改变线程优先级时，你会干扰它，并且大多数时候最终会使整个系统变慢(不仅仅是你的应用程序)而不是更快。
<标题>更新:在一个相关的not上，创建一个新线程大约需要20万个周期，销毁一个线程大约需要10万个周期。
更新2:如果问题的动机不是简单的"如果它能做到";但是为了能够扩展工作负载，那么正如@JoshW/@Servy所提到的，使用类似生产者/消费者模式的东西将允许可伸缩性，可以通过队列或服务总线方便地横向扩展到多个计算机/节点。简单地启动相同数量的线程是无法扩展到cpu数量之外的。如果您真正想要的是一个可以向外扩展的架构，因为"可用资源……"这台机器超载了多少?简直不可能。
我个人认为这是个坏主意，然而…鉴于您对其他答案的评论以及您的要求"无论创建多少后台工作人员，ObjectX都会尽快运行"……你可以使用ManualResetEvent强制你的后台工作线程阻塞。
例如，在worker代码的顶部，您可以使用WaitOne方法阻止手动重置事件。这个手动重置可以是静态的，或者作为输入参数传递，无论你的ObjectX在哪里被实例化/调用，你都可以在你的ManualResetEvent上调用。reset方法。这将阻止你所有的工人在WaitOne排队。接下来，在运行ObjectX的代码底部，调用manualreseteevent . set()方法，这将解除对工作线程的阻塞。
注意，这不是一个有效的方式来管理你的线程，但如果你"只需要让它工作"，并有时间以后改进它…我想这是一个可能的解决方案。
目标是始终有可用的资源来运行ObjectX启动的线程，无论机器有多超载。
那么线程优先级可能不是正确的工具。记住，线程优先级是邪恶的
一般来说，windows不是一个实时操作系统;特别是，win32甚至没有尝试实现软实时(IIRC, NT内核在某些时候尝试至少支持软实时子系统，但我可能错了)。因此，无法保证可用资源或时间。
另外，您是否担心系统中的其他线程?这些线程不受您的控制(如果其他线程已经处于系统最大优先级怎么办?)如果你担心应用程序中的线程…你可以控制和限制它们，使用更少的线程/worker来做更多的工作(例如，在更大的单元中批处理工作，并将其提交给worker，或者通过使用TPL或其他工具来处理和限制线程的使用)
也就是说，您可以在创建线程时进行拦截(例如查看这个问题https://stackoverflow.com/a/3802316/863564)，看看它是否是为ObjectX创建的(例如，检查它的名称)，并使用SetThreadPriority来提升它。