防止线程饥饿 - 最佳实践 [英] Prevent thread starvation - best practices
问题描述
我正在寻找有关如何防止在多个处理器/内核中同时运行多达200个线程的应用程序或服务中的线程饥饿/阻塞/竞争的更多信息。
我在网上找到的大多数例子都显示了如何协调最多3到4个线程，我计划一个有数百个的应用程序。
我已经制作了多达30个线程的应用程序但是当我超越时，我担心一些线程没有任何CPU时间而更不用说同步。
我在哪里可以找到一些非常好的文章和博客？
关于这个主题的最佳书籍是什么？
有很多关于这个主题的书籍和文章，我正在寻找最具信息性和教学性但没有用我理解的工程语言提供。
所有建议都表示赞赏。
有太多的场景需要覆盖，所以无法回答你的问题。
但是，使用比核心数更多的活动线程通常会适得其反。只有当大多数线程通常想要休眠时，例如通过等待从网络接收数据的recv（）调用等一些IO操作，您才能从使用更多线程而不是内核数量中获益。即使在这种情况下，您也希望主动控制并行执行的线程数，并启动200个线程，希望如果您有4个内核，只有4个线程要*并行运行，这不是一个好习惯。
如果你必须运行200个始终处于活动状态的并行任务，那么你必须只启动与你拥有的核心数相同数量的线程，你必须分开将任务转换为小作业，然后以您想要的任何顺序在您的线程上执行这些小作业（可能具有优先级）。这已经接近拥有自己的调度程序了。一种技术通常会产生比前一种更复杂的解决方案，使用绿色线程/协同程序（在某些Linux发行版和Windows上的光纤api上弃用ucontext POSIX api）。
使用绿色线程，您可以将线程拆分为许多绿色线程，并在用户空间中明确执行这些绿色线程之间的任务切换/协作。假设您有4个核心。然后你可以启动4个线程，如果你将每个线程分成100个绿色线程，而不是你有400个绿色线程，但只有4个线程在任何给定的时间点并行执行，你可以编写自己的调度程序，因为你可以控制绿色线程之间的任务切换。
使用绿色线程编写Web服务器的好处是多线程和异步/绿色线程实现的代码可以使用如果编写得好（因为你可以把任务切换到你自己的实现，否则阻塞函数调用，如socket读/写函数和多线程模式下相同阻塞函数调用的实现）实际上调用阻塞OS等效函数）。
I am looking for more information on how to prevent thread starvation/blocking/racing in an application or service that could possibly running up to 200 threads simultaneously across multiple processors/cores.
Most of the examples I have found online show how to coordinate between 3 or 4 threads max and I am planning a app that will have hundreds.
I've made applications that have run up to 30 threads but when going way beyond that I am worried about some threads not getting any CPU time not to mention synchronization.
Where can I find some really good articles and blogs?
What are the best books on the subject?
There are a lot of books and articles on the subject, I am looking for the most informative and instructional but not presented in an engineering language above my understanding.
All suggestions are appreciated.
There are too many scenarios to cover so it is impossible to answer you question.
But, using more active threads than the number of cores is usually counterproductive. You can have benefits from using more threads than the number of cores only if most of the threads usually want to sleep, for example by waiting on some IO operations like recv() call that receives data from the network. Even in that case you want to actively control the number of threads that execute in parallel and starting 200 threads hoping that only 4 of them will *want* to run in parallel if you have 4 cores is not a good practice.
If you have to run 200 parallel tasks that are active all the time then you have to start only the same number of threads as the number of cores you have and you have to split up the tasks into small jobs, then you execute these small jobs on your threads in whatever order you want (maybe with prioritizing). This is already near to having your own scheduler. A technique that often results in more sophisticated solution than the previous one is using green threads / coroutines (deprecated ucontext POSIX api on some linux distros and fiber api on windows).
Using green threads you can split up a thread into many green threads and you perform the tasks switching/cooperation between these green threads explicitly in user space. Lets say you have 4 cores. Then you can start 4 threads and if you split up each thread into 100 green threads than you have 400 green threads but only 4 of them are executing in parallel at any give point of time and you can write your own scheduler because you have control over the task switching between the green threads.
Writing for example a web server using green threads has the benefit that the code for the multithreaded and async/green threaded implementation can use the same servlet code if written well (because you can put the task switching into your own implementation of otherwise blocking function calls like socket read/write functions and the implementation for the same blocking function calls in multithreaded mode are actually calling the blocking OS equivalent functions).
这篇关于防止线程饥饿 - 最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
